Android Archive
Wear OS smartwatches have a dual-chipset architecture inclusive of a powerful application processor (AP) and ultra low-power co-processor microcontroller unit (MCU). The architecture has a powerful AP capable of handling complex operations en-masse, and is seamlessly coupled with a low power MCU. The Wear OS hybrid interface enables intelligent switching between the MCU or the AP, allowing the AP to be suspended when not needed to preserve battery life. It helps, for instance, achieve more power-efficient experiences, like sensor data processing on the MCU while the AP is asleep. At the same time, the hybrid interface provides a seamless transition between these states, keeping a rich and premium user experience without jarring transitions between power modes. ↫ Kseniia Shumelchyk on the Android Developers Blog The new OnePlus Watch 2 is the first to use this new architecture, and the most interesting part is that it runs not one, but two operating systems: Wear OS, which is Android, running on the “AP”, and a smaller RTOS that runs on the “MCU”. In the case of the OnePlus Watch 2, the “AP” is a Snapdragon W5, while the “MCU” is a BES 2700, an ultra low power microcontroller. I can’t seem to find any information on this “RTOS”, but I’d really love to know what it’s based on.
Android introduced support for Seamless Updates quite a long time ago at this point and, while it’s seen adoption from most, Samsung stubbornly refuses to move its devices to the A/B system. Android is now moving towards a future where A/B Seamless Updates are the only supported update mechanism, but that may not be enough to stop Samsung. ↫ Ben Schoon at 9To5Google The fact Samsung hasn’t embraced Seamless Updates yet is utterly baffling. It’s better in every single way, and there’s little to no downsides one can think of. I hope this little nudge gets them to finally get their act together.
We’re releasing the first Developer Preview of Android 15 today so you, our developers, can collaborate with us to build a better Android. Android 15 continues our work to build a platform that helps improve your productivity while giving you new capabilities to produce superior media experiences, minimize battery impact, maximize smooth app performance, and protect user privacy and security all on the most diverse lineup of devices out there. ↫ Dave Burke on the Android Developers Blog This being the first Android 15 Developer Preview, the tentpole features it would contain are not here yet. We’re looking at a lot of under-the-hood features most users will never actively notice, but are still very welcome. The Privacy Sandbox has been updated, it adds Health Connect, a secure place to store health data, partial screen sharing, and a lot more.
Winlator is an Android application that lets you to run Windows (x86_64) applications with Wine and Box86/Box64. ↫ BrunoSX That’s all you need to know. There are videos up of things like Mass Effect 2 and Fallout 3 running through this, which is incredibly neat. I’m not entirely sure what the use case is, but who cares – this is an excellent idea.
The Chrome team is excited to announce that WebGPU is now enabled by default in Chrome 121 on devices running Android 12 and greater powered by Qualcomm and ARM GPUs. Support will gradually expand to encompass a wider range of Android devices, including those running on Android 11 in a near future. This expansion will be dependent on further testing and optimization to ensure a seamless experience across a broader range of hardware configurations. ↫ François Beaufort Mind you, this is about WebGPU, not WebGL.
As a platform, we strive to help developers responsibly build new businesses and reach wider audiences across a variety of content types and genres. In response to strong demand, in 2021 we began onboarding a wider range of real-money gaming (RMG) apps in markets with pre-existing licensing frameworks. Since then, this app category has continued to flourish with developers creating new RMG experiences for mobile. ↫ Karan Gambhir, director of “Global Trust and Safety Partnerships” at Google “Real-money gaming” is the most obvious and blatant rebranding of “gambling” I have ever seen. Google, this is gambling. You’re making it easier for scumbags to target the poor and swindle them out of the little money they have. This is a shameless attempt at increasing Google’s revenue by making it easier to scam people into gambling. Everything about this post – and (mobile) gambling – is disgusting.
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.
