Android Archive
Earlier this month, we linked to a story about how Android 14 would make it impossible for users – even root users – to modify system certificates on Android. We’re ten days along now, and it seems two new methods have already been found to work around this issue, making it once again possible to edit system certificates. The original author, Tim Perry, found a way with the help of a few other people over on Mastodon, while g1a55er found a different way independently. I’m not smart enough to indicate if these methods are hacks or solid, durable, intended methods, but at least for now, this functionality remains available.
If you crack the screen on the Pixel Watch, getting it officially repaired by Google isn’t in the cards. Several Pixel Watch owners have vented their frustrations about the inability to replace cracked screens, both on Reddit and in Google support forums. The Verge has also reviewed an official Google support chat from a reader who broke their Pixel Watch display after dropping the wearable. In it, a support representative states that Google “doesn’t have any repair centers or service centers” for the device. “At this moment, we don’t have any repair option for the Google Pixel Watch. If your watch is damaged, you can contact the Google Pixel Watch Customer Support Team to check your replacement options,” Google spokesperson Bridget Starkey confirmed to The Verge. Google is exemplary at instilling confidence in buying their products.
We’ve come a long way since then, steadily retreating from openness & user control of devices, and shifting towards a far more locked-down vendor-controlled world. The next step of Android’s evolution is Android 14 (API v34, codename Upside-Down Cake) and it takes more steps down that path. In this new release, the restrictions around certificate authority (CA) certificates become significantly tighter, and appear to make it impossible to modify the set of trusted certificates at all, even on fully rooted devices. If you’re an Android developer, tester, reverse engineer, or anybody else interested in directly controlling who your device trusts, this is going to create some new challenges. The walls are slowly but surely closing in on Android.
While the Pixel 6 ushered in three years of major Android OS version updates and an additional two for security patches, that’s still nowhere near the longevity of the iPhone. Google hopes to change that on the Pixel 8 and 8 Pro with noticeably more OS updates. Looking at the mobile Android landscape, three years of OS updates – which was also the case on Qualcomm-powered Pixel phones from 2017-2021 – is less than Samsung’s promise of four, which started last year with the Galaxy S21, S22, Flip 3, and Fold 3 and continued through devices released this year, including some of the company’s more affordable releases. From what we’re hearing, Pixel 8’s update promise should surpass Samsung’s current policy on flagships and meaningfully match the iPhone. Of course, the devil is in the details, especially in those later years. For example, the Galaxy line has, in the past, adopted a quarterly approach towards the end. Even a bump to just five years of OS updates for Pixel would be enough and let the Google phone be at the top of the ecosystem, with anything beyond that squarely going after the iPhone’s record. The situation has definitely been improving – finally – but I’d still like this to be platform-wide, and not just individual manufacturers making promises. To reduce e-waste, make devices more secure and ensure longer lifespans, I’d like to see 10 years of full software support. The tech industry has a long history of garbage support and low quality – especially when it comes to software – that we would not tolerate from any other industry. It’s time the tech industry grew up and joined other industries that offer far longer and more comprehensive support.
We have been in charge of maintaining one legacy Android app for our customer. It is an app, which is used by end-customers in production, but it does not have any active development going on because it’s been ready for years now. If it would be up to us, then we would not touch that app and would let it live its life happily ever after. Of course, there is no happily ever after when closed application stores are involved, so everything went south from here. It amazes me that a lot people only seem to be waking up now to the realities so many of us warned about when closed application stores took over from freely distributable applications over a decade ago. What do you get for that 30% cut of your revenue? Delays, nonsense rejections, no people to contact, and so much corporate bureaucracy it would turn Ayn Rand socialist. This is the reality of doing business with monopolists.
Google introduced Project Mainline in Android 10, modularizing OS components so feature and security updates could be delivered through Google Play instead of regular OTA updates. Android 10 launched with 12 supported Mainline modules, but in the latest release, that number has ballooned to 37 updatable modules. Here’s a look at how Project Mainline is changing in Android 14 and beyond. If you can’t get OEMs to do their job – you have to do it yourself, it seems. The downside to this is that Android is getting less and less open by the year.
ART is the engine behind the Android operating system (OS). It provides the runtime and core APIs that all apps and most OS services rely on. Both Java and Kotlin are compiled down to bytecode executed by ART. Improvements in the runtime, compiler and core API benefit all developers making app execution faster and bytecode compilation more efficient. While parts of Android are customizable by device manufacturers, ART is the same for all devices and Google Play system updates enable a path to modular updates. Google’s been working hard to make ART more modular, and untangling it from the rest of Android for easier updates. This has led to some drastic improvements in application startup times – ART 13 cut them by 30%, Google claims – and since ART updates hit every single Android device, there’s no fragmentation. As for the future, ART 14 is on its way. In the coming months, we’ll be releasing ART 14 to all compatible devices. ART 14 includes OpenJDK 17 support along with new compiler and runtime optimizations that improve performance while reducing code size. It’s good to see that some Android improvements are not held back by Android’s update woes.
It looks like Google is desperate to move more Pixel Tablet units, with the company widely using notifications from the Google Home app to promote the new tablet launched earlier this year. Many people report seeing a “Meet the Google Pixel Tablet” banner in their notifications, with a tap on it sending them straight to its product listing on the Google Store. Samsung received hefty criticism for a similar approach to promoting new devices in the past, but it still seems like Google is attempting to jump on board with this strategy. Disgusting. Samsung, Apple, and Google are now all guilty of this, and it should be illegal.
Beta 5 is our third 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 targeting Android 14’s SDK version 34. It includes the latest fixes and optimizations, giving you everything you need to complete your testing. The final release is quite close now.
Android is the first mobile operating system to introduce advanced cellular security mitigations for both consumers and enterprises. Android 14 introduces support for IT administrators to disable 2G support in their managed device fleet. Android 14 also introduces a feature that disables support for null-ciphered cellular connectivity. 2G is not terribly secure, so being able to disable it is a welcome move.
Pixel Binary Transparency responds to a new wave of attacks targeting the software supply chain—that is, attacks on software while in transit to users. These attacks are on the rise in recent years, likely in part because of the enormous impact they can have. In recent years, tens of thousands of software users from Fortune 500 companies to branches of the US government have been affected by supply chain attacks that targeted the systems that create software to install a backdoor into the code, allowing attackers to access and steal customer data. One way Google protects against these types of attacks is by auditing Pixel phone firmware (also called “factory images”) before release, during which the software is thoroughly checked for backdoors. Upon boot, Android Verified Boot runs a check on your device to be sure that it’s still running the audited code that was officially released by Google. Pixel Binary Transparency now expands on that function, allowing you to personally confirm that the image running on your device is the official factory image—meaning that attackers haven’t inserted themselves somewhere in the source code, build process, or release aspects of the software supply chain. Additionally, this means that even if a signing key were compromised, binary transparency would flag the unofficially signed images, deterring attackers by making their compromises more detectable. I’m sure thus greatly benefits the six people who have a Pixel phone.
One of the interesting and odd thing Google does is roast itself (and others) over security issues. In this year’s Year in Review of 0-days exploited in-the-wild, Google took particular aim at the Android ecosystem for being so bad at getting patches on users’ devices that Android doesn’t even need 0-days to be exploited in the first place. These gaps between upstream vendors and downstream manufacturers allow n-days – vulnerabilities that are publicly known – to function as 0-days because no patch is readily available to the user and their only defense is to stop using the device. While these gaps exist in most upstream/downstream relationships, they are more prevalent and longer in Android. This is a great case for attackers. Attackers can use the known n-day bug, but have it operationally function as a 0-day since it will work on all affected devices. The Android update problems are not just limited to devices not receiving updates to new major Android versions – it also extends to the monthly Android security patches that somehow need to make it to users’ devices. My Galaxy S21 has been getting these updates consistently, sometimes even before Pixel devices get them, but many, many devices never get these at all, or only sporadically. The Android update problem is by far the biggest problem in the Android ecosystem, and despite Google and OEMs promising to do better every year, we’re still far, far from where we should be.
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?
