Android Q AMA Summary: Android R Screenshot changes, Desktop mode clarification, Time-based Dark mode, and more
Last year, Google’s Android team hosted an Ask Me Anything (AMA) on Reddit’s /r/AndroidDev subreddit to field questions about the Android P Developer Preview. This year, the engineering team working on the Android Q beta answered questions on Reddit. The AMA started August 1st at 12:00 PM PST and ended about an hour and a half later. 33 Google engineers were involved in the AMA, answering a ton of questions in the short time the AMA lasted. Here’s our summary of all the new information that we learned.
Android Q AMA: Everything we learned from Google
Participants from the Android Q beta team
- Adam Cohen: TLM on Android Launcher / System UI
- Adam Powell: TLM on UI toolkit/framework; views, lifecycle, fragments, support libs
- Alan Viverette: TLM, Jetpack / AndroidX
- Allen Huang: PM for UI, launcher, notifications, search integrations and more!
- Andrew Sappirstein: TLM on Android Settings
- Brahim Elbouchikhi: PM Director for Android Machine Learning and Camera (NN API, ML Kit, CameraX, Camera Platform)
- Chad Brubaker: Software Engineer, Android Platform Security
- Charmaine D’Silva: PM for Privacy
- Chet Haase: Android Chief Advocate, Developer Relations
- Diana Wong: PM, App Compatibility, non-SDK API usage, ART, NDK
- Dianne Hackborn: Manager of the Android framework team (Resources, Window Manager, Activity Manager, Multi-user, Printing, Accessibility, etc.)
- E.K. Chung: Director of UX
- Ian Lake: Software Engineer, Jetpack (Fragments, Navigation, Architecture Components)
- Iliyan Malchev: Principal Software Engineer, Project Mainline
- Jacob Lehrbaum: Director of Developer Relations for Android
- Jake Wharton: Software Engineer, Jetpack
- Jamal Eason: PM, Android Studio
- Jeff Bailey: TLM, Android Open Source Project (AOSP)
- Jeff Sharkey: Software Engineer, Android Framework
- Jeffrey van Gogh: Android Studio, Compilers
- Jen Chai: PM, Location and Context, Auth, Autofill, non-SDK API usage, ART
- Karen Ng: Group PM for Android Developer Tools, Android Studio, Android Tookit and Jetpack
- Paul Bankhead: Director of Product Management, Google Play
- Rohan Shah: Product Manager, Android System UI
- Romain Guy: Manager of the Android Toolkit/Jetpack team
- Sagar Kamdar: Director of Product Management, Android
- Sat K: Director of Engineering, Android Connectivity
- Selim Cinek: Software Engineer, Android System UI
- Stephanie Saad Cuthbertson: Senior Director of Product Management, Android
- Sumir Kataria: Software Engineer, Jetpack (WorkManager)
- Travis McCoy: PM, Android Platform
- Trystan Upstill: Distinguished Engineer, Lead for Android System UI & Intelligence
- Vinit Modi: PM, Android Camera
OEMs can no longer kill apps when the user swipes them away in recents
If you’ve ever used a smartphone from a Chinese brand, then you’ve probably dealt with annoying “battery optimization” features that kill all your favorite apps in the background. Not only is this behavior annoying for users who expect certain apps to continue running in the background for whatever reason, but it’s also annoying for developers who have to suffer poor reviews from users who don’t understand that it’s not the app’s fault. While Google is still not fully addressing this matter (they hand-waved the issue away by stating that this behavior is likely already in violation of the Android Compatibility Definition Document requirements), the company is taking action against one “battery saving” behavior change employed by some OEMs.
“To help with the situation, we’ve added a CTS test in Android Q to ensure that an app is not killed upon being swiped from Recents.”
Android R may bring more changes to screenshots than we expected
Google plans on adding scrolling screenshots in Android R, but at the same time, the Android team is “taking a close look at how [they] can improve the whole screen-[X] experience for R.” Thus, we may see other improvements to the screenshot (AND screencast) behavior in the next major Android version.
Clarifying Android Q’s new Desktop Mode
The first public beta release of Android Q brought a hidden desktop mode interface to the AOSP and Pixel Launcher. Although Google briefly touched upon the feature during a Google I/O session, we’ve never heard directly from Google how the new feature fits into the Android ecosystem. Google now clarifies:
“In Q AOSP ‘desktop mode’ is a developer option targeted for application developers. It allows them to test their apps in multi-display and freeform windowing mode environments. Previously there was no convenient way to test app behavior on a secondary display and with freely resizable windows on stock Android. This feature is not productized on its own and is not meant for regular users at the moment. Nevertheless, it is the baseline of Android platform for OEMs to innovate and make great products.”
Thus, we can expect to see OEMs build upon Android Q’s native desktop mode. For example, the OnePlus 7 Pro supports display out over HDMI, so it’s possible that OxygenOS 10 based on Android Q will have its own desktop mode interface in the future. We’re also hoping that Google builds upon the feature for the upcoming Pixel 4.
Time-based Dark Mode
Android Q finally brings a widely requested feature: system-wide dark mode. Currently, the dark mode can either be manually enabled in Settings or via a Quick Settings tile, or it can be automatically activated when Battery Saver is enabled. Before Android Q, there was an option to enable dark mode based on the time of day, but that option was deprecated. According to Chris Banes:
“There are a few reasons why this is deprecated (not removed) in AppCompat v1.1.0: it requires apps to request location permissions to be accurate, and even with a valid location the sunrise/sunset time calculations can be buggy.”
When asked about these bugs, Mr. Banes states that “calculating sunrise/sunsets are notoriously difficult, especially for locations close to north/south poles.” A user brings up that Night Light, available since Android 7.1 Nougat, can be toggled automatically based on Sunset/Sunrise schedules. Mr. Banes then states that since Night Light uses CalendarAstronomer from ICU4J, it uses a “big chunk of code which we wouldn’t want AppCompat to depend on.” However, the team does state that this feature is “something [they] will be looking into.”
Mandatory Camera2 API/Camera HAL3 support for Android Q launch devices
Google introduced the Camera2 API to better define how apps can interact with the individual cameras connected to your smartphone. While Google encourages smartphone vendors to “expose all their physical cameras to developers,” many vendors choose not to do so even though “the API itself is not preventing them today.” This means that many third-party camera apps cannot use the secondary or tertiary camera modules on modern smartphones. Progress is being made, however, as Android Q has improved LOGICAL_MULTI_CAMERA, an API which gives developers better access to all cameras on a device and which gives OEMs control over power consumption and management of multiple camera states.
Furthermore, Google says that they’ve added requirements for all devices launching with Android Q to natively support Camera2 API/Camera HAL3. According to Vinit Modi:
“Starting with Android P, new devices shipping with 1GB or more RAM are required to natively use HALv3/camera2. Android Q onwards all new devices are required to natively support HALv3/camera2. Unfortunately upgrades from HALv1 to HALv3 are fairly complex over the air and may have unexpected consequences hence we had to limit the scope to new devices.”
Interestingly, Modi’s statement about normal RAM Android P launch devices contradicts what we were told earlier by Google and what’s published on the Image Test Suite page online.
Dynamic App Theming with Jetpack Compose
Sony’s OMS theming framework was added to AOSP quite a few releases back, but it’s only intended for OEMs to build upon. We already know that Google is against the use of runtime resource overlays by users to theme apps, but for developers, the company is hoping that its Jetpack Compose UI framework will bring forward “interesting approaches to dynamic theming.”
Vulkan-backend for Skia to render the UI
Last year, we spotted a discussion among Google engineers talking about their plans to have the Android framework use the Vulkan graphics API for UI rendering. While it’s now possible to enable the Vulkan hardware-accelerated backend without your phone crashing, we haven’t heard any concrete plans from Google about when they plan on rolling out these changes. This AMA doesn’t answer that question, but at least we have confirmation that it’s still in the works. According to Romain Guy:
“The team has been working on a Vulkan backend for Skia, the 2D renderer used by Android, but it is not enabled by default currently. The UI and Canvas still go through OpenGL ES.”
Making Android Q’s gesture bar more dynamic
Some on XDA still think that Android’s new gestures are a mess, but I personally think they’re fine. If you play around with the new gestures in Android Q for a bit, though, you’ll notice that the gesture bar doesn’t move with your finger. It also sticks around on screens where it isn’t needed, like the home screen or recent apps overview. Allen Huang says that they “totally agree there are opportunities” to make the “navigation line less static.” He further says that “this is something we’re working on – but also balancing so it’s not distractingly appearing/disappearing.”
Improvements to the Storage Access Framework
The many changes in Android Q have majorly improved the security and privacy of the platform. One such change, called “Scoped Storage,” limits apps’ access to files on the external storage in a way that makes sense; music apps shouldn’t need to see your gallery, for instance. File manager apps running in Android Q have to use an API called the Storage Access Framework to continue working like normal, but some developers see this API as inferior to what was previously available. Jeff Sharkey from Google says the team has addressed some of these developers’ complaints:
“We made some SAF performance improvements in the latest Android Q Beta releases; could you check your benchmarks against the latest Beta? Also ensure you’re using a ContentProviderClient when running any bulk operations.”
Project Treble improved Android Pie adoption versus Android Oreo
We’ve already seen how Project Treble, a major low-level rearchitecting of the Android framework, has improved the adoption of newer Android OS versions. Google credits Treble behind the slew of smartphone vendors joining the Android P beta last year and Android Q beta this year. Iliyan Malchev, the lead Project Treble and Mainline engineer, says that Android Pie adoption was “3 times” that of Android Oreo at the end of 2018.
In the same comment, Dick Dougherty teases that more useful metrics are in the works for the Android version distribution chart. The chart was last updated in May, but its data is more useful for journalists than app developers.
Screen Recording is still a WIP
Early Android Q betas added a feature flag for a basic screen recorder, but the platform itself has majorly improved the utility of screen recording by allowing for apps to capture the audio from other apps. Stephanie Saad Cuthbertson said the team was considering “how we could do better on screen recording needs as recently as yesterday.” Other smartphone brands like OnePlus, ASUS, Huawei, and Samsung have robust screen recorders that can record the internal audio, so Google will be playing catch up here.
Dark Theme All The Things!
In case you missed it, Google is adding dark mode to most of their apps. Stephanie Saad Cuthbertson says to expect all “major apps” to support a dark theme “by official [Android Q] release.” Even Google Chrome, which currently forces a page reload when the system-wide dark theme is enabled, will be updated to no longer refresh when the theme is changed.
Yes, Third-Party Launchers will work with Gestures (Eventually)
Android’s gestures are kind of broken when you use a third-party launcher. That’s because the recent apps UI is contained within the stock launcher app, and Google hasn’t yet worked out a way to have the same seamless transitions we see when using gestures with the stock Pixel Launcher. Adam Cohen affirms Google’s plans to address these issues “as quickly as possible post release.” He further says that the incompatibility “will be addressed in post-Q update, and backported for new devices launching with Q.”
Dynamic/Logical Partitions are not here to kill custom ROMs
In order to support Dynamic System Updates in Android Q, certain devices like the Google Pixel 3 and Pixel 3 XL make use of logical partitions. These partitions can be dynamically resized. This change has proven challenging in getting root access working, and some developers are concerned that custom ROMs are being targeted. Iliyan Malchev assures us that the intention is not to constrain custom ROMs. As he explains:
“Dynamic partitions are not meant to constrain what you can do with custom ROMs. They are simply a solution to the problem of fixed partition sizes and lack of a safe way to repartition devices on OTA. Prior to dynamic partitions, if an OEM made a mistake in sizing e.g. the system partition, then they would be constrained by that choice, making it practically impossible to upgrade a device after a certain point. Some OEMs do repartition their devices on OTA as a matter of practice, but this is a) not officially supported in Android, and b) changing the partition table is considered quite risky. Dynamic partitions aim to alleviate the problem by introducing a level of indirection between the physical partition table and the OS sees. This in turn allows us to safely adjust partition sizes on OTA. As for custom ROMs, you should not be at all constrained any more than you are today with what you can do. Supporting custom ROMs is and continues to be something each individual OEM decides to enable.”
Project Mainline – ART Module and Support Length
Mainline is a new initiative by Google that aims to standardize certain libraries and packages so they can be updated independently of platform updates. Some have wondered why the Android Runtime (ART) is not yet a Mainline module, but I was told at Google I/O that the complexity involved in modularizing ART prevented them from including it as one of the initial APEX packages. As explained by both Iliyan Malchev and Diana Wong:
“Making updates to the Runtime (especially performance & GC fixes and core libraries) is definitely something we’re exploring in the context of mainline. We can see a lot of benefits to being able to make these updates consistent across all devices and across multiple releases with mainline. It’s also a huge technical challenge as we think about how to do this best for developers, and likely a multi-year effort. It’s not something Mainline can currently do, but certainly something we’re thinking about.”
Regarding the benefit of Project Mainline, one user asked about the length of Mainline updates. In response, Iliyan Malchev says that “this is a policy question that we are still evaluating, but we want to update Mainline modules on a device for as long as possible.” XDA Recognized Developer luca020400 inquired about whether prebuilt Mainline modules will be provided so custom ROM developers can merge updates, and in response, Jeff Bailey reiterates that “the modules that are splitting off of AOSP will have source releases matching each module release.” We can already see the progression of new APEX modules in AOSP such as one for the Neural Networks API.
CameraX meets ML Kit
At I/O this year, Google introduced the CameraX Jetpack library. This library is designed to make it easier for developers to support Android’s Camera2 API while maintaining compatibility all the way back to Android Lollipop. Vinit Modi teases that the company is working on integrating CameraX with ML Kit, Google’s machine learning Firebase SDK, so developers can feed image frames into ML Kit for analysis.
CameraX Vendor Extensions and Release Date
The developer of a camera app laments the fact that advanced camera features like the Google Pixel’s Night Sight aren’t accessible to third-party camera apps. This is supposed to be solvable with CameraX vendor extensions, to which Jeff Sharkey from Google says that “all Pixel devices are optimized for CameraX Core.” He teases that “the Extensions aspect is going to be supported on new and upcoming devices.” Furthermore, Google is “working with several manufacturers to be able to bring their device capabilities to developers and users alike.” While not directly confirmed, it’s possible we may see features like Night Sight on the Google Pixel 4 become available to third-party camera apps that use the CameraX library.
Mr. Sharkey states that Google is targeting a beta release for the end of this year.
Memory Management Improvements in Android Q
The Pixel 3 was lambasted for having numerous issues post-launch, but Google has done a lot to address these issues via numerous post-launch updates. Memory management has been one of the Pixel 3’s weakest aspects, but things should be a bit better in the Android Q release. According to Selim Cinek:
“In SystemUI for example, we had various big refactoring efforts in Q to reduce the RAM usage of notifications and other surfaces.”
Will we finally get wireless ADB?
If you want to wirelessly debug your phone, you’ll have to root your device. Jamal Eason from the Android Studio team says that they’re currently addressing the feasibility of this feature.
Does Google still test on tablets?
XDA Recognized Developer Luk1337 asked whether Google still tests AOSP UX on tablets. It’s a fair question considering the dearth of good Android tablets and the bugs present in current releases. Allen Huang says that Google does still “test and make fixes each year” and that the company is working closely with partners “to ensure a good Android tablet experience.”
There are a lot more posts in the full thread over on Reddit. What I’ve covered here summarizes all the new information we learned, but several Googlers (especially Dianne Hackborn) go into their reasoning behind cutting X feature or not implementing Y permission. I recommend you read the full AMA if you want to understand the Android team’s decision-making a bit better.
Want more posts like this delivered to your inbox? Enter your email to be subscribed to our newsletter.