Android Archive
This is a big shift from the Google of old. People in this industry talk, even when they work for the companies that make these products. Previously, Google was very cautious about doing anything that would create a rift between itself and all the vendors that made Android what it is today. Very little was held back because Google needed to keep Samsung happy, and Samsung wouldn’t be happy if a cool new Android thing didn’t work on the next Galaxy phone. Now Google is building all these cool things but calling them Pixel features. Features that will probably never come to a Galaxy phone or any other brand of phone. And it’s building the hardware to make them even better and to unleash even cooler things in the future. Things that are Pixel features. Things that will never be on a Galaxy phone. You can’t even really call Android an open source mobile operating system anymore at this point, and it seems the latest few Pixels are really starting to drive the point home that for Google, Android is not really their mobile brand anymore – it’s Pixel. We’ll see how far they’re willing to take this, but I wouldn’t be surprised if they’ve barely even started. What’s the life expectancy of AOSP?
Last year we wrote about how moving native code in Android from C++ to Rust has resulted in fewer security vulnerabilities. Most of the components we mentioned then were system services in userspace (running under Linux), but these are not the only components typically written in memory-unsafe languages. Many security-critical components of an Android system run in a “bare-metal” environment, outside of the Linux kernel, and these are historically written in C. As part of our efforts to harden firmware on Android devices, we are increasingly using Rust in these bare-metal environments too. One day I’m going to wake up to my wife looming over me, and with an expressionless face she’ll say “our children are now written in Rust”.
Google unveiled the Pixel 8 and Pixel 8 Pro phones and the Pixel Watch 2 today, and while I no longer spend too many words on new phone releases on OSNews these days, this new phone does come with a rather major promise by Google. The Pixel 8 will get seven years of Android OS updates with security patches, as well as quarterly Feature Drops. Launching with Android 14, the Pixel 8 and 8 Pro will see updates to Android 15, 16, 17, 18, 19, 20, and 21 – assuming the naming doesn’t change before 2030. We’ll have to see if Google keeps its promise – not an unreasonable concern – but if they do, this is unprecedented in the Android world, and even surpasses Apple’s OS support for the iPhone. This is the kind of meaningful, important dedication I like to see, and I sincerely hope Google sticks to its promise. Regardless, the combination of some of the new camera features – which are great for taking photos and videos of small children, which I have now – and this support promise, as well as my carrier offering a free Pixel Watch 2 with any Pixel 8 Pro purchase, has made it pretty easy for me to choose the Pixel 8 Pro as my next phone when my contract runs out 12 October.
Google has released Android 14 – for Pixel devices, anyway. Android Police’s review summarises this rather small release: After months and months of beta testing, Android 14 has finally arrived in stable. There was a tremendous buildup of excitement around this release after the rather lackluster Android 13, which only introduced some small refinements following the big Android 12 design refresh on Pixel phones. Android 14 certainly stays true to the look that Google established with Material You two years ago, but it adds much-needed refinement and customization to the mix. While the beta was buggier than usual, the final release is making up for this long period of bugs with tons of new features, thoughtful design improvements, and a more polished experience all over the place. Google’s own release announcement isn’t exactly long either, so there isn’t that much interesting going on in Android 14, it seems.
Whenever Apple releases a major OS update, as it did last Monday with iOS 17, iPadOS 17, and watchOS 10, developers – both large but especially indie – release a slew of day one updates to support the latest platform features. I understand how the Android update model is inherently different from Apple’s. Namely, updates start out only on Google’s Pixel phones, which have a relatively small market share, while Samsung’s lion’s share of Android phones are typically weeks or months behind. Third-party Android developers don’t have an incentive to update on day one as the majority of their users won’t be getting the new OS for quite some time. It really depends on what kind of applications you’re looking at. Yes, the popular applications from big players like Facebook or Spotify are terrible at adopting new Android features, but there’s definitely a vibrant community of developers who care these days, and it’s entirely possible to use only applications that follow the latest features and visual style of Android. It’s definitely not as good as it is on iOS, and it surely takes a bit longer, but it’s also not nearly as bad as some make it out to be.
When you plug an Android phone into a PC, you have the option to change the USB mode between file transfer/Android Auto (MTP), USB tethering (NCM), MIDI, or PTP. In Android 14, however, a new option can appear in USB Preferences: USB webcam. Selecting this option switches the USB mode to UVC (USB Video Class), provided the device supports it, turning your Android device into a standard USB webcam that other devices will recognize, including Windows, macOS, and Linux PCs, and possibly even other Android devices. Webcam support in Android 14 is not enabled out of the box, however. In order to enable it, four things are required: a Linux kernel config needs to be enabled, the UVC device needs to be configured, the USB HAL needs to be updated, and a new system app needs to be preloaded. iOS recently introduced this feature as well, and it makes a ton of sense for Android to go down the same path.
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.
