Android Archive
It’s CES, and Google has made a number of disparate, small announcements about upcoming Android features. 9To5Google has collected them all, and it seems there’s not many things of interest here, nor are there any big changes or improvements. The only thing that stands out to me is that easy Bluetooth device pairing is coming to more scenarios. First announced at CES 2022, Fast Pair support is rolling out to the Chromecast with Google TV “in the next month.” This seamless Bluetooth pairing with an onscreen “Connect now” prompt for headphones is coming to “more Google TV devices later this year.” Abner Li for 9To5Google Bluetooth pairing is an unpleasant experience, so seeing fast pairing become more popular is good news.
One of the changes Google is forced to make because of the antitrust trial vs. Epic concerns how sideloading works on Android. Right now, sideloading an app on Android requires users to open an APK and, if the source app is not already approved, follow a link to settings where that option can be enabled before they can return to the installation process. Following the changes outlined in this settlement, Android will be required to simplify this process by condensing it down to one screen. Android will still be able to outline the risks of sideloading on this screen, but it will be a one-step process. The new screen will say: Ben Schoon at 9to5Google I’m not sure if this is a better approach. The way I have sideloading set up on my Android devices is that only File, Google’s file manager for Android, is allowed to install any APK, so even if, for some reason, I download a harmful APK accidentally through a phishing email or my browser, it will just sit inert in my downloads folder until I were to actively open Files and install said APK. It’s safeguard I most likely don’t need, but I do like having installing APKs limited to just the Google file manager for my own peace of mind. This change would, if I’m reading things correctly, make it so that any application can more easily be given the permission to install APKs, which seems like it’s not going to encourage many more people to intentionally sideload, but will perhaps make people accidentally grant random applications the permission to do so. It’s an odd change, for sure, and I hope there’s some way to disable this if Google implements this outside of the US as well.
App developer Elias Saba has had some bad luck with Digital Millennium Copyright Act (DMCA) takedowns. His Android TV app Downloader, which combines a web browser with a file manager, was suspended by Google Play in May after several Israeli TV companies complained that the app could be used to load a pirate website. Google reversed that suspension after three weeks. But Downloader has been suspended by Google Play again, and this time the reason is even harder to understand. Based on a vague DMCA notice, it appears that Downloader was suspended simply because it can load the Warner Bros. website. Application stores are basically random number generators. The worst possible applications, from non-functional garbage to ad-ridden gambling games designed to prey on children, make up the bulk of what’s on offer, but functional, useful applications spiral into Kafkaesque bureaucratic dark holes. Being a mobile developer in 2023 is a nightmare.
Google today is announcing strengthened protections for Android developers publishing apps to its Google Play store. The changes are a part of Google’s broader efforts at keeping low-quality and unsafe apps out of its app store and off consumers’ devices, which also recently included the launch of a new real-time app scanning feature to combat malicious apps. Today, the company says it will now require new Android developers with personal accounts to test their app with a minimum of 20 people for at least 2 weeks prior to publication. It additionally plans to increase its investment in the app review processes, warning of potential slowdowns in approvals for a small number of apps as these changes roll out. At first glance, this sounds like a good idea – more testing leads to better applications, is the reasoning – but it’s going to be a massive burden for many small indie developers to even find 20 testers. In my experience, it’s usually the small indie teams or individual developers that make the best applications on Android, while the large, well-known brands release steady streams of garbage. In other words, this is going to disproportionately affect the wrong people.
It’s definitely clear that Huawei is pulling the plug on Android apps, but it’s still rather hard to believe that the company is throwing away Android (AOSP) entirely. For that, we’ll just have to wait and see, as more digging can be done when “Next” hits the scene next year. The Chinese market is big enough to sustain its own application ecosystem, and many western services are banned in China anyway, so the Play Store is of lesser value there. It makes sense for Huawei to not waste time and resources on maintaining Android application compatibility.
Xiaomi also has bad news for MIUI users who wish to unlock their smartphones, saying they won’t get updated to HyperOS. “Previous operating systems, such as MIUI 14, still retain the ability to unlock, but users will no longer receive any Xiaomi HyperOS updates if they leave their devices in an unlocked state,” the company told us. The Chinese brand clarified in a follow-up email that HyperOS updates won’t be available if you’ve unlocked your phone’s bootloader, regardless of whether you’re on MIUI 14 or HyperOS. However, the company said you’ll receive HyperOS updates if you choose to lock your device again. This applies to all Xiaomi devices outside of China. I rarely say this, but with this new “HyperOS” skin being the most blatant iOS ripoff I’ve ever seen, just get an iPhone if you want that experience that badly.
Google engineers on Wednesday posted an initial “request for comments” set of patches that re-implement Android’s Binder code within the Linux kernel in the Rust programming language rather than C. Binder remains a critical piece of Android’s software stack and for increasing the robustness and security, Google is pursuing a rewrite of the C code in Rust. Binder is responsible for inter-process communication (IPC) and other tasks on Android while replacing it with memory-safe Rust code should be a big step-up for system security. Rust is everywhere.
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 OSAlert 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.
