Android Archive
The Pixel 8 hardware (Tensor G3) supports the ARM Memory Tagging Extension (MTE), and software support is available both in Android userspace and the Linux kernel. This feature is a powerful defense against linear buffer overflows and many types of use-after-free flaws. I’m extremely happy to see this hardware finally available in the real world. You can enable this feature in both Android and the kernel, as the post explains. Sadly, the post does not explain if there’s any downsides to enabling this extension, and I’m certainly not the right person to investigate that. Does anyone in our audience know?
During his testimony, Pichai revealed a tidbit on how Google operates that gives a better look behind the curtain and could help explain users’ frustration with Android phones not seeing security updates. According to Pichai, Google financially incentivizes OEMs to update their phones. Companies that keep phones current with the latest security patches see a higher revenue share from Google services than those that don’t. In other words, the amount of money an OEM makes from you using Google products on its device is correlated to how often it keeps that device up to date with security patches. This means Google intentionally strongarms OEMs to be better about updating phones, which is something we didn’t know before. We knew that Google mandates two years of updates for any Android phone and strongly encourages more extended support than that, but we didn’t realize there were financial incentives involved. I’m honestly not entirely sure if this wasn’t known before, but this is an interesting approach for Google to take. If it’s not financially interesting for OEMs to update their Android devices, why not give them a bigger slice of the Google revenue pie to incentivise them? I’d prefer proper update windows be legally mandated – I wouldn’t be surprised if the EU is working on that somewhere – but in the meantime, I’ll take this rare case of Google’s interests lining up with consumers’ interests.
Support for RISC-V in Android is taking another step forward. The latest update that we have is that now not only are we accepting patches, but we have begun to mature support for RISC-V in Android. RISC-V is a modular ISA, meaning that there are a large number of optional extensions. We have also determined an initial set that we feel is critical to ensure that any CPU running RISC-V will have all of the features we expect to achieve high performance. This set includes the rva22 profile as well as the vector and vector crypto extensions. Excellent news.
Does anybody care about Android 14? This year’s release of the world’s most popular operating system feels like one of the smallest ever, bringing just a handful of new features. Even during the Android portion of Google’s big I/O keynote, Google spent most of its time showing off a new generative AI feature that creates wallpapers for you, as if there aren’t enough wallpapers in the world. Last year’s Android 13 release felt small, but that was because it was the second major Android OS release that year. Android 12L—the big tablet and foldable release—came out earlier. What’s Android 14’s excuse? We’re not really sure. We still have a few things to go over, though, like new lock screen customizations, genuinely exciting changes to the way the back button works, and a pile of under-the-hood changes. Android 14 is definitely the smallest version number update I remember from Android history. I’m not entirely sure why this wasn’t called Android 13.1.
As generative AI models become more widely available, you may be integrating them into your apps. In line with Google’s commitment to responsible AI practices, we want to help ensure AI-generated content is safe for people and that their feedback is incorporated. Early next year, we’ll be requiring developers to provide the ability to report or flag offensive AI-generated content without needing to exit the app. You should utilize these reports to inform content filtering and moderation in your apps – similar to the in-app reporting system required today under our User Generated Content policies. I like that this will be a system-wide requirement, which will slowly make it a common sight on Android, and thus, something users expect and know how to work with. In the same blog post announcing this new generative “AI” policy, Google also announced tighter rules around certain broad application permissions, limiting full-screen notifications, and more/
Today, we are making Google Play Protect’s security capabilities even more powerful with real-time scanning at the code-level to combat novel malicious apps. Google Play Protect will now recommend a real-time app scan when installing apps that have never been scanned before to help detect emerging threats. Scanning will extract important signals from the app and send them to the Play Protect backend infrastructure for a code-level evaluation. Once the real-time analysis is complete, users will get a result letting them know if the app looks safe to install or if the scan determined the app is potentially harmful. This enhancement will help better protect users against malicious polymorphic apps that leverage various methods, such as AI, to be altered to avoid detection. There’s a lot you can say about these kinds of security tools, but with how much access our smartphones have to our data, banking information, credit/debit cards, and so on – I don’t think it’s unreasonable at all for Google (and Apple, if they are forced to enable sideloading by the EU) to employ technologies like these. As long as the user can still somehow bypass them, or disable them altogether, possibly through some convoluted computer magic that might scare them, I don’t see any issues with this. …that is, assuming it won’t be used for other ends. The step from “scanning for malware” to “scanning for unapproved content” like downloaded movies or whatever isn’t that far-fetched in today’s corporate world, and if totalitarian regimes get their hands on stuff like that, it could get a lot worse.
Have you ever wanted to read 69 pages of in-depth information about the security frameworks in Android, past to present to future? Now’s your chance. To share and document the latest Android security capabilities, we’ve published an update to the Android Security Paper. The paper provides a comprehensive overview of the platform’s built-in, proactive security across hardware, anti-exploitation, Google Security Services and the range of management APIs available for businesses and governments alike. You might want some coffee to prevent dozing off.
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.
