Android Archive
Mobile work phones running in the cloud: safe & instantly available smartphones for your team. Complete with a phone number, accessible from your browser. I find the pricing a bit steep, but the concept in and of itself is pretty cool: it’s an Android VM in the cloud running /e/OS. I’m not entirely sure what I’d use it for, but something about it I find intriguing.
The Android KitKat (KK) platform was first released ~10 years ago and since then, we’ve introduced many innovative improvements and features for Android, which are unavailable on KK. As of July 2023, the active device count on KK is below 1% as more and more users update to the latest Android versions. Therefore, we are no longer supporting KK in future releases of Google Play services. KK devices will not receive versions of the Play Services APK beyond 23.30.99. It’s time.
Last year at Google I/O, we shared some big changes coming to the Play Store for large screen devices. Since then, we’ve seen even more people using large screens for work and play, across millions of active Android devices. Apps and games play a critical role in shaping the on-device experience, so we’ve redesigned the Play Store to help users get the most from their tablets, Chromebooks, and foldables. Today, we’re introducing four major updates to help users find high-quality large screen apps on Play: refreshed app listing pages, ranking and quality improvements, streamlined store navigation, and a split-screen search experience. I’m glad Google seems to be finally doing the things it need to do to make Android applications feel more at home on larger displays. While I believe the problem has been somewhat overblown by tech media, there’s no denying iPadOS has a wider and more optimised tablet application offering, and Google’s got a lot of work to do to catch up.
Android 14 introduces a number of new features for app stores, including an “update ownership” API that lets an app store claim ownership over an app it installs. If any other app store tries to push an update to that app, Android will throw up a dialog asking you what they want to do. The dialog asks you if you want to “update this app from ” since “this app normally receives updates from ” and warns that “by updating from a different source, you may receive future updates from any source on your phone.” You can choose to cancel or update anyway, which is good since it means one app store can’t lock you out of getting app updates from somewhere else. When taken in isolation, I think this dialog is a good addition to Android – I personally see no issues with informing users of the very valid risk that come with installing applications from outside the Play Store, especially ones coming from random websites (and not from APKMirror or F-droid or similar, more well-known sources). There are real risks associated with doing so, and it’s a good idea to warn people of this in the highly unlikely event they both accidentally download a random APK and open it to install it. However, the ‘when’ clause is doing a lot of heavy lifting here. Google has been slowly locking Android down for years now, and it’s not unreasonable to assume that this is simply yet another stop along the way in that process. I don’t think Google will ever fully remove sideloading from Android, but they sure will do whatever they can to make it as hard, cumbersome, annoying, and frustrating as possible.
Are you an Android developer with applications on the Play Store? Well, you might want to know that Google is about to publish your phone number on the Play Store for everyone to see. We’re renaming the “Contact details” section on your app’s store listing to “App support” and adding a new “About the developer” section to help users learn more about you. This may show verified identity information like name, address, and contact details. Google is doing this in an attempt to “build user trust”, but to me it seems rife for abuse. Does this really mean every small indie developer is going to have their personal phone number published for all to see? I also wonder what’s going to be displayed under Google’s own applications – it’s notoriously difficult to get anyone at Google on the phone, so will they be excluded from this new policy? Will they be allowed to link to a recording?
Speaking of beta programs and doing it right – here’s how things are going at the other end of the spectrum. Today we’re bringing you Android 14 Beta 4, continuing our work on polish and performance as we get closer to the general availability release of Android 14. Beta 4 is available for Pixel Tablet and Pixel Fold, in addition to the rest of the supported Pixel family, so you can test your applications on devices spanning multiple form factors and directly experience the work we’re doing to improve the large-screen and foldable device experience. The fact Android betas are only available on an incredibly small subset of Android devices stands in such stark contrast to how Apple does their program. Of course, we all know why that’s the case, but that doesn’t mean Google gets a pass. I have an Android device running Android 13. I should be able to install Android 14 betas. End of story. Rant aside, how far along the development process for Android 14 are we? Beta 4 is our second Platform Stable Android 14 release, which means that the developer APIs and all app-facing behaviors are final for you to review and integrate into your apps, and you can publish apps on Google Play to devices running Android 14 at the official API level. That indicates we’re relatively close to release, meaning most Android users can expect to upgrade somewhere halfway 2024, or when they buy a new device, or not at all.
I recently discovered a secret browser located inside the “Manage my account” popup that Android has in various apps (quite important apps, such as Settings, and all Google suite apps). The browser even bypasses parental control! A secret browser that is entirely different from whatever browsers you have installed on your Android device? I’m sure that won’t present any problems whatsoever. Then you have two methods which I don’t know what they do, but they sound scary. As this is a secret-browser of the ‘on-device encryption’ feature, I can guess, they are both used to set your local encryption keys. So it looks like a malicious website can put their keys there, and try to make you pay for them! I think this is the time to tell you that I already reported this to Google, and they say this is not a security vulnerability (probably because this secret browser is not very popular), and that the parental control bypass is the “Intended Behavior”. Oh. Good.
It’s no secret that the Android Open Source Project has been languishing compared to the distributions (?) of Android that are actually being used by Google itself (on their Pixel phones) and OEMs such as Samsung, Sony, and others. Now, it seems Google has taken a pretty substantial step in further gutting AOSP – it has deprecated both the Dialer and Messaging applications in AOSP, with the following message: This app is not actively supported and the source is only available as a reference. This project will be removed from the source manifest sometime in the future. This means that soon, if you build the Android Open Source Project, you will no longer be able to send messages or make phone calls without adding your own messaging and dialer applications. In the grand scheme of things, this doesn’t matter all that much since every OEM already uses their own applications, but for the open source operating system that is Android, this is another nail in the coffin. Due to the slow erosion of functionality from AOSP, as well as the transfer of functionality from AOSP to closed-source Google applications and frameworks, we’re fast approaching a point where you can’t really state that AOSP is a full open source mobile operating system anymore. Is a mobile operating system that can’t send messages or make phone calls really complete?
Your T95 is infected with malware pre-installed, ready to do whatever the C2 servers decide. Yes, malware from Amazon straight to your door! If they insist on selling these devices they really should add an “Includes Malware” category in the Android TV section. I find it absolutely baffling that Amazon is full of sketchy garbage like this, and nobody really seems to care. Amazon itself, lawmakers, consumers – everybody just takes it for granted?
Google’s keynote at the RISC-V Summit was all about bold proclamations, though. Lars Bergstrom, Android’s director of engineering, wants RISC-V to be seen as a “tier-1 platform” in Android, which would put it on par with Arm. That’s a big change from just six months ago. Bergstrom says getting optimized Android builds on RISC-V will take “a lot of work” and outlined a roadmap that will take “a few years” to come to fruition, but AOSP started to land official RISC-V patches back in September. Another vote of confidence for RISC-V.
Ars Technica: Guess what has happened! Łukasz Siewierski, a member of Google’s Android Security Team, has a post on the Android Partner Vulnerability Initiative (AVPI) issue tracker detailing leaked platform certificate keys that are actively being used to sign malware. The post is just a list of the keys, but running each one through APKMirror or Google’s VirusTotal site will put names to some of the compromised keys: Samsung, LG, and Mediatek are the heavy hitters on the list of leaked keys, along with some smaller OEMs like Revoview and Szroco, which makes Walmart’s Onn tablets. These companies somehow had their signing keys leaked to outsiders, and now you can’t trust that apps that claim to be from these companies are really from them. To make matters worse, the “platform certificate keys” that they lost have some serious permissions. I tend to not really focus on security issues, because more often than not they amount to baseless scaremongering for clicks (or worse, to scare people into buying antivirus software), but this one seems possibly serious enough to warrant attention. I’m just not entirely sure how bad this can actually turn out to be, and the vague statements from Samsung, Google, and other sure aren’t helping in cleaning up the confusion.
In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies. These are low-level components that require a systems language which otherwise would have been implemented in C++. To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code. We don’t expect that number to stay zero forever, but given the volume of new Rust code across two Android releases, and the security-sensitive components where it’s being used, it’s a significant result. It demonstrates that Rust is fulfilling its intended purpose of preventing Android’s most common source of vulnerabilities. Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production. These numbers don’t lie.
Change is many things: scary, exciting, inevitable. Android is changing all the time, and for a while now we’ve been anticipating a major shift in terms of software support, one that would see the platform abandon its oldest software — Android will go 64-bit-only, dropping compatibility for old 32-bit apps. The biggest question has been “when?” Would the Pixel Tablet demand 64-bit apps? Could we be sitting around until Android 14 to make the switch? Apparently Google just got tired of waiting, and quietly launched the Pixel 7 and Pixel 7 Pro without support for 32-bit apps. The inevitable march of progress. The move to 64bit killed quite a few old games on iOS, and I’m sure the same will happen to Android. However, if an application hasn’t been updated that long, it might be a good idea to search for an alternative, of which there will be many, since application stores are nothing if not filled to the brim with shameless ripoffs.
The Android update treadmill continues with the release of Android 13. It’s one of the smallest Android releases in recent memory, with barely any user-facing features to point to. Keep in mind, though, that this update follows the monster Android 12 release from last year. This is also the second Android OS release this year, the previous one being the tablet-focused Android 12L update that was rushed out the door in March. We would have a bit more meat to work with if Android 12L was part of this release, but as it is, we’re left with a grab bag of features for Android 13. It includes many foundational features for Android tablets and smart displays, but there’s not much here for phones. Even so, there are things to discuss, so let’s dive in. Ars Technica’s usual deep dive into every new Android release, and despite Android 13 being a relatively minor release, there’s still more than enough to cover.
With the rollout of Android 13 to the Pixel 6 and 6a, Google posted an interesting warning on the system image website: Once you flash Android 13, you can never go back to the old version. That’s still the case for anyone wanting a fully functional phone, but now, Google has posted an Android 12 “developer support image” that will let developers roll back their phones even after upgrading. The “developer” branding on the image means it’s not fully functional, but it will be good enough for app testing. Not being able to roll back would be terrible if Android 13 came with some sort of gamebreaking bug, so this is a welcome release.
Today we’re launching our Developer Preview of the new Cross device SDK for Android. First announced during the Google I/O ‘22 Multi-device development session, our Cross device SDK allows developers to build rich multi-device experiences with a simple and intuitive set of APIs. This SDK abstracts away the intricacies involved with working with device discovery, authentication, and connection protocols, allowing you to focus on what matters most—building delightful user experiences and connecting these experiences across a variety of form factors and platforms. Google intends to expand this tool to non-Android operating systems soon.
Today, Google is releasing Android 13 for Google Pixel smartphones, following months of developer previews and beta releases. It’s an update that polishes a lot of the changes that Android 12 brought to the table, while also introducing a ton of small, helpful features across the board that aims to improve privacy, security, and usability. Alongside the update, the company has also announced that Android 13’s source code is now available in AOSP. It’ll be a while before Android 13 lands in most of our hands.
The /e/ OS operating system provides a user-friendly alternative to Android for people who want the Android experience without the reliance on Google and associated manufacturer-related applications and telemetry. Compared to LineageOS, /e/ provides a more unified experience out of the box, with a suitable suite of default open source applications and a system-based application store. Despite the fact that /e/ borrowed from various pre-existing open source projects to create its default applications, none looks out of place. It’s a good choice for people looking to de-Google, but the rather lacklustre device support is a big problem, forcing you to buy a new device if you want to give this a go. That’s not really /e/’s fault, of course, but it’s an issue nonetheless.
With the addition of the developer-generated Data safety section this year, Google Play removed the old list of app permissions. The Play Store is now reversing this decision in response to user feedback and will have both coexist. This was a baffling decision to begin with – the Data safety section relied on developers being honest and truthful about their privacy practices and permissions usage, which was never going to work out with the amount of downright scams and sleaziness targeting children that are in the Play Store (and App Store).
Hello Nova Community, I’m Kevin Barry, the creator of Nova Launcher. I’ve made, make and will continue to make Nova Launcher. Today I’m announcing that Branch has acquired Nova Launcher, and hired myself and Cliff Wade (Nova Community Manager). Branch has also acquired Sesame Search and hired the Sesame Crew (Steve Blackwell and Phil Wall). I’ll continue to control the direction and development of Nova Launcher, and that direction is unchanged. Nova focuses on power users and customization. I will be adding some features powered by Branch, they’ll be optional like most features in Nova. This is a tough pill to swallow. I’ve been a dedicated Nova user since… I honestly can’t even remember, and to me, Nova equals Android, and it’s always been clear Nova thoroughly and truly understood what demanding Android users were looking for. I have really never used any other launcher, and it’s the first application I install on all my Android devices. Seeing this vital application bought up by a mobile analytics form of all things is gut-wrenching. Several decades covering this industry have taught me that acquisitions like this pretty much exclusively mean doom, and usually signal a slow but steady decline in quality and corresponding increase in user-hostile features. I’m always open to being proven wrong, but I don’t have a lot of hope. In any event, I guess it’s time to find another launcher.
