Android Archive
Android 15 started rolling out to Pixel devices Tuesday and will arrive, through various third-party efforts, on other Android devices at some point. There is always a bunch of little changes to discover in an Android release, whether by reading, poking around, or letting your phone show you 25 new things after it restarts. In Android 15, some of the most notable involve making your device less appealing to snoops and thieves and more secure against the kids to whom you hand your phone to keep them quiet at dinner. There are also smart fixes for screen sharing, OTP codes, and cellular hacking prevention, but details about them are spread across Google’s own docs and blogs and various news site’s reports. ↫ Kevin Purdy at Ars Technica It’s a welcome collection of changes and features to better align Android’ theft and personal privacy protection with how thieves steal phones in this day and age. I’m not sure I understand all of them, though – the Private Space, where you can drop applications to lock them behind an additional pin code, confuses me, since everyone can see it’s there. I assumed Private Space would also give people in vulnerable positions – victims of abuse, journalists, dissidents, etc. – the option to truly hide parts of their life to protect their safety, but it doesn’t seem to work that way. Android 15 will also use “AI” to recognise when a device is yanked out of your hands and lock it instantly, which is a great use case for “AI” that actually benefits people. Of course, it will be even more useful once thieves are aware this feature exists, so that they won’t even try to steal your phone in the first place, but since this is Android, it’ll be a while before Android 15 makes its way to enough users for it to matter.
Remember earlier this year, when Android Authority discovered Google was experimenting with letting you run full Chrome OS on your Android device? In case you were wondering if that particular piece of spaghetti was sticking to the wall, I’m sorry to disappoint you it isn’t. Despite creating the Ferrochrome launcher app, which would’ve made the whole thing a one-click affair, Google has just removed the whole concept from the Android code base altogether. Unfortunately, though, Google has decided to kill its Ferrochrome launcher app. This was revealed to us by a code change recently submitted to the AOSP Gerrit. The code change, which hasn’t been merged yet, removes the entire Ferrochrome launcher app from AOSP. Google’s reason for removing this app is that it doesn’t plan to ship it or maintain its code. It seems that Google is shifting towards using the Linux-based Debian distro instead of Chrome OS as its testbed for AVF development. ↫ Mishaal Rahman at Android Authority I’m not really sure if people were really asking for something like this, and to Google’s credit – for once – the company never even so much as hinted at releasing this to the general public. Still, the idea of carrying just your phone with you as your primary computer, and plugging into a display and input devices as the need arises, remains something a lot of people are fascinated with, and putting Chrome OS on your Android phone would’ve been one way to achieve this goal. Despite decades of attempts, it seems not even the smartest people in Silicon Valley can crack this nut. Perhaps they should ask Gemini to solve it for them? It doesn’t involve pizza’s, glue, or rocks, so who knows – it might surprise them!
The push towards memory safe programming languages is strong, and for good reason. However, especially for bigger projects with a lot of code that potentially needs to be rewritten or replaced, you might question if all the effort is even worth it, particularly if all the main contributors would also need to be retrained. Well, it turns out that merely just focusing on writing new code in a memory safe language will drastically reduce the number of memory safety issues in a project as a whole. Memory safety vulnerabilities remain a pervasive threat to software security. At Google, we believe the path to eliminating this class of vulnerabilities at scale and building high-assurance software lies in Safe Coding, a secure-by-design approach that prioritizes transitioning to memory-safe languages. This post demonstrates why focusing on Safe Coding for new code quickly and counterintuitively reduces the overall security risk of a codebase, finally breaking through the stubbornly high plateau of memory safety vulnerabilities and starting an exponential decline, all while being scalable and cost-effective. ↫ Jeff Vander Stoep and Alex Rebert at the Google Security Blog In this blog post, Google highlights that even if you only write new code in a memory-safe language, while only applying bug fixes to old code, the number of memory safety issues will decreases rapidly, even when the total amount of code written in unsafe languages increases. This is because vulnerabilities decay exponentially – in other words, the older the code, the fewer vulnerabilities it’ll have. In Android, for instance, using this approach, the percentage of memory safety vulnerabilities dropped from 76% to 24% over 6 years, which is a great result and something quite tangible. Despite the majority of code still being unsafe (but, crucially, getting progressively older), we’re seeing a large and continued decline in memory safety vulnerabilities. The results align with what we simulated above, and are even better, potentially as a result of our parallel efforts to improve the safety of our memory unsafe code. We first reported this decline in 2022, and we continue to see the total number of memory safety vulnerabilities dropping. ↫ Jeff Vander Stoep and Alex Rebert at the Google Security Blog What this shows is that a large project, like, say, the Linux kernel, for no particular reason whatsoever, doesn’t need to replace all of its code with, say, Rust, again, for no particular reason whatsoever, to reap the benefits of a modern, memory-safe language. Even by focusing on memory-safe languages only for new code, you will still exponentially reduce the number of memory safety vulnerabilities. This is not a new discovery, as it’s something observed and confirmed many times before, and it makes intuitive sense, too; older code has had more time to mature.
To empower tablet users to get more done, we’re enhancing freeform windowing, allowing them to run multiple apps simultaneously and resize windows for optimal multitasking. Today, we’re excited to share that desktop windowing on Android tablets is available in developer preview. For app developers, the concept of Android apps running in freeform windows has already existed with solutions like Samsung DeX and ChromeOS. Updating your apps to support adaptive layouts, more robust multitasking, and adaptive inputs will ensure your apps work well on large screens across the Android ecosystem. ↫ Francesco Romano on the Android Developers Blog The long-running saga of Google trying to develop proper freeform windowing support for Android seems to finally be bearing fruit. Countless attempts came and went, usually in developer releases, hidden behind flags, rarely, if ever talked about, but now it’s finally not only part of an Android beta release anyone with a Pixel Tablet can install and try out, Google is also openly talking about and touting it as a feature, so we might actually perhaps maybe see this in a non-beta release at some point. The way it works is both surprising and rather unsurprising. Instead of the Apple approach, which seems to entail a deep disdain for traditional windowing, Google is pretty much embracing the things we expect a windowing system to have, from window titlebars with close and maximise widgets, to a traditional dock-like taskbar permanently available at the bottom of the screen. If you click or tap on a little downward arrow on the titlebar, you can choose options like displaying windows side-by-side, much like on Windows. A very welcome ‘feature’ is the ability to tear off Chrome tabs and turn them into their own windows, just like in a traditional desktop environment. Google also opted for an interesting approach that reminds me somewhat of the “desktop” mode on Windows RT. Since Windows RT was ARM-based and entirely locked-down, the only classic Win32 applications you could run were those bundled with Windows as well as Microsoft Office. To access these, Windows RT would launch a full-screen tablet application that contained the entire traditional Windows desktop, and you’d run your classic Win32 applications in there. Android’s new windowing system seems to be doing something similar: once you enter the freeform windowing mode, all future applications will also launch as windows. In the task switcher, however, they’re all contained within a single “desktop” entry that you can close if you want to. That desktop entry seems to take the shape of a live view of the “desktop”, including the various windows you have opened. This way, you can have a dedicated “desktop” with freeform windows alongside any fullscreen tablet applications you also happen to be running. It’s perhaps not the most integrated or elegant approach, but it’s dead-simple and easy to grasp. This new windowing environment also provides application developers with the option of allowing multiple instances of a single application to be launched, say launching two text editor windows side-by-side. This seems to be a specific property developers need to enable, though, and considering Android’s tablet adoption history, that’s anything but a given at this point. Of course, it shouldn’t come as a surprise that applications need to be able to resize gracefully, too. If you want to play with it, you’ll need a Pixel Tablet running Android 15 QPR1 Beta 2, or just use the simulator. I really hope this takes off and developers support the various APIs for optimal integration (I’m not getting my hopes up), since proper freeform windowing that doesn’t feel like an ugly, barely functional hack is something I’ve been wanting on Android for a long time.
It seems Google is hell-bent on removing anything from Android that makes the platform stand apart from iOS. One of the features of Android and the Play Store that users of rooted and/or de-Googled phones will be familiar with is SafetyNet Attestation, something that Android applications can use to check, among other things, if the device it’s running on is rooted or not, and take any action from there based on that information. Notoriously, some banking applications on Android will refuse to work on rooted and/or de-Googled devices because of this. Earlier this year, at Google I/O, the company unveiled the successor of SafetyNet Attestation, called the Google Play Integrity API, and it comes with a whole lot more functionality for developers to control what their application can do on devices based on the status of the device and the application binary in question. Play Integrity will let the developer’s application know if its binary has been tampered with, if Google Play Protect is enabled, if the Android device it’s running on is “genuine”, and a whole lot more. Based on that information, the application could decide to warn users when they’re about to do something sensitive that their device is rooted, or it could just throw up its hands entirely and refuse to function at all – and there’s really not much the user can do about this. A new capability of the Play Integrity API is that developers can now also determine where it came from – i.e., if it was sideloaded or installed through a non-Play application store – and then throw up a dialog allowing the user to switch to the version from the Play Store instead. Doing so will delete the original binary and all its data, and replace it with the Play Store version. The problem here is that the only other option is to cancel, and not have the application load at all. As you can see, the remediation dialog tells you to “get this app from Play” in order to continue using it. There’s an option to close the dialog, but there’s no way to bypass it entirely. If you close the dialog, a response is sent to the app that lets the developer know so they can decide whether to continue blocking access. ↫ Mishaal Rahman at Android Authority Several applications appear to already be using this new capability, and while it won’t mean much for people running Google’s, Samsung’s, or any other “blessed by Google” version of Android on unrooted devices, people running, say, /e/OS, GrapheneOS, LineageOS, or any other de-Googled and/or rooted device is going to be having a very bad time if more and more applications adopt this capability. If you’re running a device without Play Services, relying solely on the vast and varied library of applications from F-Droid, for instance, while also sideloading a few applications only available in the Play Store, you could very well be running into problems. We’ll have to see just how widespread this capability becomes, but I can already foresee this becoming yet another major headache for anyone trying to use a smartphone that isn’t from blessed by Apple or Google. Personally, I’m lucky in that Swedish banking and ID applications worked on de-Googled Android phones, but with the expanding reach of the Play Integrity API, as well as possible “let’s enable this by default” shenanigans by Google, I’m definitely worried about this remaining so in the future.
Today we’re releasing Android 15 and making the source code available at the Android Open Source Project (AOSP). Android 15 will be available on supported Pixel devices in the coming weeks, as well as on select devices from Samsung, Honor, iQOO, Lenovo, Motorola, Nothing, OnePlus, Oppo, realme, Sharp, Sony, Tecno, vivo, and Xiaomi in the coming months. We’re proud to continue our work in open source through the AOSP. Open source allows anyone to build upon and contribute to Android, resulting in devices that are more diverse and innovative. You can leverage your app development skills in Android Studio with Jetpack Compose to create applications that thrive across the entire ecosystem. You can even examine the source code for a deeper understanding of how Android works. ↫ Matthew McCullough at the Android Developers blog While it’s great that we’re still getting open source Android releases, the reality of it is that Google has eroded so much away from the Android Open Source Project that AOSP has become effectively useless. Back in the olden days, AOSP was a complete mobile operating system, but those days are long behind us. Google has moved so much from AOSP over to proprietary frameworks, applications, and cloud services that running that it’s no longer a complete package, which is a huge shame. Still, AOSP plays an important role for the custom ROM community and the various companies and communities making privacy-first, de-Googled Android versions, and for that reason alone it’s good that it still exists, even in its gutted state. Android 15’s AOSP release will surely find its way to LineageOS, /e/OS, GrapheneOS, and the countless other alternatives to butchered Android OEM versions and people seeking a more private smartphone experience. As for when Android 15 will hit Pixels – that’s going to be a few weeks from now, later than usual after the source release.
On the whole, I’m satisfied that Lineage OS, as I use it, is preventing nearly all of Google’s data collection. I don’t install or use any Google services, I don’t enable A-GPS, I don’t use Chromium or the built-in browser. I could eliminate more arcane aspects of data collection – like the Internet connectivity check – if I wanted to take the trouble. I don’t think that taking reasonable precautions to avoid becoming part of Google’s data collection economy makes me a tinfoil-hatter. Nevertheless, I would probably use GrapheneOS instead, if I had devices that supported it. Ironically, if I wanted to use GrapheneOS, I’d have to buy Google-branded mobile devices, which is an irony that really stings. ↫ Kevin Boone The existence of Android versions like LineageOS, GrapheneOS, /e/OS, and similar, other de-Googled mobile operating systems is absolutely vital. The market is dominated by Google Android and iOS, and since full alternatives that aren’t Android or iOS are effectively impossible, de-Googled Android is the best we’re going to get. Regulators must ensure that banks, government ID applications, popular messaging platforms, and similarly crucial applications work 100% reliably on de-Googled Android, and do not require Google Play Services in any way, shape, or form. In The Netherlands, there are basically three banks that control the market, and there’s really just one messaging application that rules the country – WhatsApp – and their use is effectively required to participate in society. Consequently, these applications and platforms should be accessible by as many people as possible, and that definitely includes de-Googled Android devices. Being alive should not be taxed by Apple or Google.
A page is the granularity at which an operating system manages memory. Most CPUs today support a 4 KB page size and so the Android OS and applications have historically been built and optimized to run with a 4 KB page size. ARM CPUs support the larger 16 KB page size. When Android uses this larger page size, we observe an overall performance boost of 5-10% while using ~9% additional memory. In order to improve the operating system performance overall and to give device manufacturers an option to make this trade-off, Android 15 can run with 4 KB or 16 KB page sizes. ↫ Steven Moreland Android 15 has been reworked to be page-size agnostic, meaning that a single binary can run on either 4 KB or 16 KB versions of Android. Any assumptions about page size have been removed from Android as well, the EROFS and F2FS file systems as well as UFS are now compatible with 16 KB, and a whole lot more things have been changed and refactored to make this transition as effortless as possible. Application developers do need to do a few things, though. They’ll need to recompile their binaries with 16 KB alignment, after which they’ll need to be tested in a 16 KB version of an Android device or emulator. To make this possible, starting with Android 15 QPR1, the Pixel 8 and Pixel 8 Pro will get a new develop option that will reboot the device in 16 KB mode. In addition, Android Studio will gain a 16 KB emulator target as well. The 16 KB page size is an ARM-only feature, so people running the emulator on x86 devices will emulate the 16 KB page size, in which “the Kernel runs in 4 KB mode, but all addresses exposed to applications are aligned to 16 KB”. Of course, Google urges Android developers to test for 16 KB page sizes as soon as possible.
About two years ago, the very popular and full-featured Android launcher Nova Launcher was acquired by mobile links and analytics company Branch. This obviously caused quite the stir, and ever since, whenever Nova is mentioned online, people point out what kind of company acquired Nova and that you probably should be looking for an alternative. While Branch claimed, as the acquiring party always does, that nothing was going to change, most people, including myself, were skeptical. Several decades covering this industry have taught me that acquisitions like this pretty much exclusively mean doom, and usually signal a slow but steady decline in quality and corresponding increase in user-hostile features. I’m always open to being proven wrong, but I don’t have a lot of hope. ↫ Thom Holwerda Up until a few days ago, I have to admit I was wrong. Nova remained largely the same, got some major new features, and it really didn’t get any worse in any meaningful way – in fact, Nova just continued to get better, adopted all the new Android Material You and other features, and kept communicating with its users quite well. After a while, I kind of forgot all about Nova being owned by Branch, as nothing really changed for the worse. It’s rare, but it happens – apparently. So I, and many others who were skeptical at first as well, kept on using Nova. Not only because it just continued being what I think is the best, most advanced, and most feature-rich launcher for Android, but also because… Well, there’s really nothing else out there quite like Nova. I’m sure many of you are already firing up the comment engine, but as someone who has always been fascinated by alternative, non-stock mobile device launchers – from Palm OS, PocketPC, and Zaurus, all the way to the modern day with Android – I’ve seen them all and tried them all, and while the launcher landscape is varied, abundant, and full of absolutely amazing alternatives for every possible kind of user, there’s nothing else out there that is as polished, feature-rich, fast, and endlessly tweakable as Nova. So, I’ve been continuing to use Nova since the acquisition, interchanged with Google’s own Pixel Launcher ever since I bought a Pixel 8 Pro on release, with Nova’s ownership status relegated to some dusty, barely used croft of my mind. As such, it came as a bit of a shock this week when it came out that Branch had done a massive round of lay-offs, including firing the entire Nova Launcher team, save for Nova’s original creator, Kevin Barry. Around a dozen or so people were working on Nova at Branch, and aside from Barry, they’re all gone now. Once the news got out, Barry took to Nova Launcher’s website and released a statement about the layoffs, and the future of Nova. There has been confusion and misinformation about the Nova team and what this means for Nova. I’d like to clarify some things. The original Nova team, for many years, was just me. Eventually I added Cliff to handle customer support, and when Branch acquired Nova, Cliff continued with this role. I also had contracted Rob for some dev work prior to the Branch acquisition and some time after the acquisition closed we were able to bring him onboard as a contractor at Branch. The three of us were the core Nova team. However, I’ve always been the lead and primary contributor to Nova Launcher and that hasn’t changed. I will continue to control the direction and development of Nova Launcher. ↫ Kevin Barry This sounds great, and I’m glad the original creator will keep control over Nova. However, with such a massive culling of developers, it only makes sense that any future plans will have to be scaled down, and that’s exactly what both Barry and other former team members are saying. First, Rob Wainwright, who was laid off, wrote the following in Nova’s Discord: To be clear, Nova development is not stopping. Kevin is remaining at Branch as Nova’s only full time developer. Development will undoubtedly slow with less people working on the app but the current plan is for updates to continue in some form. ↫ Rob Wainwright Barry followed up with an affirmation: I am planning on wrapping up some Nova 8.1 work and getting more builds out. I am going to need to cut scope compared to what was planned. ↫ Kevin Barry In other words, while development on Nova will continue, it’s now back to being a one-man project, which will have some major implications for the pace of development. It makes me wonder if the adoption of the yearly drop of new Android features will be reduced, and if we’re going to see much more unresolved bugs and issues. On top of that, one has to wonder just how long Branch is for this world – they’ve just laid off about a hundred people, so what will happen to Barry if Branch goes under? Will he have to find some other job, leaving even less time for Nova development? And if Branch doesn’t go under, it is still clearly in dire financial straits, which must make somehow monetising Nova users in less pleasant ways come into the picture. The future of Nova was definitely dealt a massive blow this week, and I’m fearful for its future. Again.
Android 14 introduced the ability for application stores to claim ownership over application updates, to ensure other installation sources won’t accidentally update applications they shouldn’t. What is still lacking, however, is for users to easily change the update ownership for applications. In other words, say you install an application by downloading an APK from GitHub, and later the application makes its way to F-Droid, you’ll get warning popups when F-Droid tries to update that application. That’s about to change, it seems, as Android Authority discovered that the Play Store application seems to be getting a new feature where it can take ownership of an application’s updates. A new flag spotted in the latest Google Play Store release suggests that users may see the option to install updates for apps downloaded from a different source. As you can see in the attached screenshots, the Play Store will show available updates for apps downloaded from different sources. On the app listing, you’ll also see a new “Update from Play” button that will switch the update ownership from the original source to the Play Store. ↫ Pranob Mehrotra at Android Authority Assuming this functionality is just an API other application stores can also tap into, this will be a great addition to Android for power users who use multiple application stores and want to properly manage which store updates what applications. It’s not something most people will ever really use or need, but if you’re the kind of person who does need it – it’ll become indispensable.
The assault on a user’s freedom to install whatever they want on what is supposed to be their phone continues. This time, it’s Samsung adding an additional blocker to users installing applications from outside the Play Store and its own mostly useless Galaxy Store. Technically, Android already blocks sideloading by default at an operating system level. The permission that’s needed to silently install new apps without prompting the user, INSTALL_PACKAGES, can only be granted to preinstalled app stores like the Google Play Store, and it’s granted automatically to apps that request it. The permission that most third-party app stores end up using, REQUEST_INSTALL_PACKAGES, has to be granted explicitly by the user. Even then, Android will prompt the user every time an app with this permission tries to install a new app. Samsung’s Auto Blocker feature takes things a bit further. The feature, first introduced in One UI 6.0, fully blocks the installation of apps from unauthorized sources, even if those sources were granted the REQUEST_INSTALL_PACKAGES permission. ↫ Mishaal Rahman I’m not entirely sure why Samsung felt the need to add an additional, Samsung-specific blocking mechanism, but at least for now, you can turn it off in the Settings application. This means that in order to install an application from outside of the Play Store and the Galaxy Store on brand new Samsung phones – the ones shipping with OneUI 6.1.1 – you need to both give the regular Android permission to do so, but also turn off this nag feature. Having two variants of every application on your Samsung phone wasn’t enough, apparently.
Android, like many other operating systems, uses the open-source Linux kernel. There are several different types of Linux kernel releases, but the type that’s most important to Android is the long-term support (LTS) one, as they’re updated regularly with important bug fixes and security patches. Starting in 2017, the support lifetime of LTS releases of Linux was extended from two years to six years, but early last year, this extension was reversed. Fortunately, Google has announced that moving forward, they’ll support their own LTS kernel releases for four years. Here’s why that’s important for the security of Android devices. ↫ Mishaal Rahman at Android Authority I fully support the Linux kernel maintainers dropping the LTS window from six to two years. The only places where such old kernels were being used were embedded devices and things like smartphones vendors refused to update to newer Android releases, and it makes no sense for kernel maintainers to be worrying about that sort of stuff. If an OEM wants to keep using such outdated kernels, the burden should be on that OEM to support that kernel, or to update affected devices to a newer, supported kernel. It seems Google, probably wisely, realised that most OEMs weren’t going to properly upgrade their devices and the kernels that run on them, and as such, the search giant decided to simply create their own LTS releases instead, which will be supported for four years. Google already maintains various Android-specific Linux kernel branches anyway, so it fits right into their existing development model for the Android Linux kernel. Some of the more popular OEMs, like Google itself or Samsung, have promised longer support life cycles for new Android versions on their devices, so even with this new Android-specific LTS policy, there’s still going to be cases where an OEM will have to perform a kernel upgrade where they didn’t have to before with the six year LTS policy. I wonder if this is going to impact any support promises made in recent years.
If there was ever a “will they, won’t they?” love story in mobile computing, it’s definitely Google’s on and off again relationship with Android’s desktop mode. There have been countless hints, efforts, and code pertaining to the mythical desktop mode for Android, but so far, Google has never flipped the switch and made it available. It’s 2024, Android 15 development is in full swing, and it seems Google and Android’s desktop mode are dating again. This past spring, Google added DisplayPort support to the Pixel 8 and Pixel 8 Pro in a Feature Drop update, allowing for easy wired connections to external monitors. Then, tinkering in Android 14 QPR3 Beta 2.1, Mishaal Rahman was able to get a new desktop interface up and running, complete with Android apps running in resizeable floating windows. It’s not confirmed that Android 15 will ship with a built-in desktop mode, but the bones are there. It does make me wonder, though: why? What would a desktop interface add to Android? ↫ Taylor Kerns at Android Police I’m actually fairly convinced Android could, indeed, serve as an excellent desktop operating system, but without any official backing by Google, it’s always been a massive hack to use Android with a mouse and keyboard. It’s not so much the hardware support – it’s all there – but rather the software support, and the clunky way common Android UI tasks feel when performing them with a mouse. I’ve installed Android desktop ‘distributions’ countless times, and the third-party hacks they use, like clunky taskbars and custom menus and so on, make for a horrid user experience. Samsung DEX seems to be the only somewhat successful attempt at adding a desktop mode to Android, but it can’t be installed on any regular PC or laptop, and requires cumbersome cabling or expensive docks, making it more of a curiosity than a true desktop mode in the sense most of us are thinking of. This feature needs to come from Google itself, and it needs to be something third parties can use in their ROMs and x86 builds so we can truly use Android on a desktop. I don’t believe that’s going to happen, though. It’s clear Google is more interested in pushing Chrome OS for desktop and laptop use, and it seems more likely that any desktop mode that gets added to Android is going to be similar in nature to DEX – something you can only use by hooking up your phone to a display and configuring wireless input devices. Cool, but not exactly something that will turn Android into a desktop contender.
Google released Android 15 beta 2 today, and with it, they unveiled some more of the new features coming to Android later this year when the final release lands. Android 15 comes with something called a private space, an area with an extra layer of authentication where you can keep applications and data hidden away, such as banking applications or health data. It’s effectively a separate user profile, and shows up as a separate area in the application drawer when unlocked. When locked, it disappears entirely from sight, share sheets, and so on. Another awesome new feature is Theft Detection Lock, which uses Google “AI” to detect when a phone is snatched out of your hands by someone running, biking, or driving away, and instantly locks it. Theft like this is quite common in certain areas, and this seems like an excellent use of “AI” (i.e., accelerometer data) to discourage thieves from trying this. There’s also a bunch of smaller stuff, like custom vibration patterns per notification, giving applications partial access to only your most recent photos and videos, system-wide preferences for which gender you’d like to be addressed as in gendered languages (French gets this feature first), and a whole lot more. Developers also get a lot to play with here, from safer intents to something like ANGLE: Vulkan is Android’s preferred interface to the GPU. Therefore, Android 15 includes ANGLE as an optional layer for running OpenGL ES on top of Vulkan. Moving to ANGLE will standardize the Android OpenGL implementation for improved compatibility, and, in some cases, improved performance. You can test out your OpenGL ES app stability and performance with ANGLE by enabling the developer option in Settings -> System -> Developer Options -> Experimental: Enable ANGLE on Android 15. ↫ Android developer blog You can install Android 15 beta 2 on a number f Pixel devices and devices from other OEMs starting today. I installed it on my Pixel 8 Pro, and after a few hours I haven’t really noticed anything breaking, but that’s really not enough time to make any meaningful observations. Google also detailed Wear OS 5. Later this year, battery life optimizations are coming to watches with Wear OS 5. For example, running an outdoor marathon will consume up to 20% less power when compared to watches with Wear OS 4. And your fitness apps will be able to help improve your performance with the option to support more data types like ground contact time, stride length and vertical oscillation. ↫ Android developer blog Wear OS 5 will also improve the Watch Face Format with more complications, which is very welcome, because the selection of complications is currently rather meager. Wear OS 5 will also ship later this year.
Google I/O, the company’s developer conference, started today, but for the first time since I can remember, Android and Chrome OS have been relegated to day two of the conference. The first day was all about “AI”, most of which I’m not even remotely interested in, except of course where it related to Google’s operating system offerings. And the company did have a few things to say about “AI” on Android, and the general gist is that yeah, they’re going to be stuffing it into every corner of the operating system. Google’s “AI” tool Gemini will be integrated deeply into Android, and you’ll be able to call up an overlay wherever you are in the operating system, and do things like summarise a PDF that’s on screen, summarise a YouTube video, generate images on the fly and drop them into emails and conversations, and so on. A more interesting and helpful “AI” addition is using it to improve TalkBack, so that people with impaired vision can let the device describe images on the screen for them. Google claims TalkBack users come across about 90 images without description every day (!), so this is a massive improvement for people with impaired vision, and a genuinely helpful and worthwhile “AI” feature. Creepier is that Google’s “AI” will also be able to listen along with your phone calls, and warn you if an ongoing conversation is a scamming attempt. If the person on the other end of the line claiming to be your bank asks you to move a bunch of money around to keep it safe, Gemini will pop up and warn you it’s a scam, since banks don’t ask you such things. Clever, sure, but also absolutely terrifying and definitely not something I’ll be turning on. Google claims all of these features take place on-device, so privacy should be respected, but I’m always a bit unsure about such things staying that way in the future. Regardless, “AI” is coming to Android in a big way, but I’m just here wondering how much of it I’ll be able to turn off.
Now that Android – since version 13 – ships with the Android Virtualisation Framework, Google can start doing interesting things with it. It turns out the first interesting thing Google wants do with it is run Chrome OS inside of it. Even though AVF was initially designed around running small workloads in a highly stripped-down build of Android loaded in an isolated virtual machine, there’s technically no reason it can’t be used to run other operating systems. As a matter of fact, this was demonstrated already when developer Danny Lin got Windows 11 running on an Android phone back in 2022. Google itself never officially provided support for running anything other than its custom build of Android called “microdroid” in AVF, but that’s no longer the case. The company has started to offer official support for running Chromium OS, the open-source version of Chrome OS, on Android phones through AVF, and it has even been privately demoing this to other companies. At a privately held event, Google recently demonstrated a special build of Chromium OS — code-named “ferrochrome” — running in a virtual machine on a Pixel 8. However, Chromium OS wasn’t shown running on the phone’s screen itself. Rather, it was projected to an external display, which is possible because Google recently enabled display output on its Pixel 8 series. Time will tell if Google is thinking of positioning Chrome OS as a platform for its desktop mode ambitions and Samsung DeX rival. ↫ Mishaal Rahman at Android Authority It seems that Google is in the phase of exploring if there are any OEMs interested in allowing users to plug their Android phone into an external display and input devices and run Chrome OS on it. This sounds like an interesting approach to the longstanding dream of convergence – one device for all your computing needs – but at the same time, it feels quite convoluted to have your Android device emulate an entire Chrome OS installation. What a damning condemnation of Android as a platform that despite years of trying, Google just can’t seem to make Android and its applications work in a desktop form factor. I’ve tried to shoehorn Android into a desktop workflow, and it’s quite hard, despite third parties having made some interesting tools to help you along. It really seems Android just does not want to be anywhere else but on a mobile touch display.
Although Google has shown significant progress in recent weeks in improving RISC-V support in Android, it seems that we’re still quite a bit away from seeing RISC-V hardware running certified builds of Android. Earlier today, a Senior Staff Software Engineer at Google who, according to their LinkedIn, leads the Android Systems Team and works on Android’s Linux kernel fork, submitted a series of patches to AOSP that “remove ACK’s support for riscv64.” The description of these patches states that “support for risc64 GKI kernels is discontinued.” ↫ Mishaal Rahman Google provided Android Authority with a statement, claiming that Android will continue to support RISC-V. What these patches do, however, is remove support for the architecture from the Generic Kernel Image, which is the only type of kernel Google certifies for Android, which means that it is now no longer possible to ship a certified Android device that uses RISC-V. Any OEM shipping a RISC-V Android device will have to create and maintain its own kernel fork with the required patches. This doesn’t seem to align with Google’s statement. So, unless Google intends to add RISC-V support back into GKI, there won’t be any officially certified Android devices running on RISC-V. Definitely an odd chain of events here.
Today we’re taking the next step toward our vision for a more open computing platform for the metaverse. We’re opening up the operating system powering our Meta Quest devices to third-party hardware makers, giving more choice to consumers and a larger ecosystem for developers to build for. We’re working with leading global technology companies to bring this new ecosystem to life and making it even easier for developers to build apps and reach their audiences on the platform. Meta Horizon OS is the result of a decade of work by Meta to build a next-generation computing platform. To pioneer standalone headsets, we developed technologies like inside-out tracking, and for more natural interaction systems and social presence, we developed eye, face, hand, and body tracking. For mixed reality, we built a full stack of technologies for blending the digital and physical worlds, including high-resolution Passthrough, Scene Understanding, and Spatial Anchors. This long-term investment that began on the mobile-first foundations of the Android Open Source Project has produced a full mixed reality operating system used by millions of people. ↫ Facebook’s blog In summary, Facebook wants the operating system of their Quest series of virtual reality devices – an Android Open Source Project fork optimised for this use – to become the default platform for virtual reality devices from all kinds of OEMs. Today, they’re announcing that both Asus and Lenovo will be releasing devices running this Meta Horizon OS, with the former focusing on high-end VR gaming, and the latter on more general use cases of work, entertainment, and so on. Facebook will also be working together with Microsoft to create a Quest “inspired by Xbox”. The Meta Quest Store, the on-device marketplace for applications and games, will be renamed to the Meta Horizon Store, and the App Lab, where developers can more easily get their applications and games on devices and in the hands of consumers as long as they meet basic technical and content guidelines, will be integrated into the Meta Horizon Store for easier access than before. In addition, in a mildly spicy move, Facebook is openly inviting Google to bring the Google Play Store to the VR Android fork, “where it can operate with the same economic model it does on other platforms”. The odds of me buying anything from Facebook are slim, so I really hope this new move won’t corner the market for VR headsets right out of the gate; I don’t want another Android/iOS duopoly. I’m not particularly interested in VR quite yet – but give it a few more years, and I certainly won’t pass up on a capable device that allows me to play Beat Saber and other exercise-focused applications and games. I just don’t want it to be a Facebook device or operating system.
New TVs that launch with Android TV 14 or later on Linux kernel 5.15 or higher will be required to meet Google’s Generic Kernel Image (GKI) requirements in order to pass certification! This means that GKI is now enforced on all major Android form factors with AArch64 chipsets: handhelds, watches, automotive, & televisions. ↫ Mishaal Rahman What this means is that all the major Android form factors will be running kernels that adhere to the GKI requirements, which means SoC and board support is not part of the core kernel, but instead achieved through loadable modules. This should, in theory, make it easier to provide long-term support.
After two months of developer previews, Google has finally released Android 15 Beta 1. While the beta usually offers more user-facing changes, Google is still pretty light on details with this build, giving us only a few more details on what we can expect. Instead, the company is pointing to Google I/O for more details, which will take place on May 14 this year, basically confirming that this is when we will get the second beta with more features. ↫ Manuel Vonau There’s very little of interest in this beta, so unless you’re really into Android development, I’d wait out installing any betas until after Google I/O.
