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.”
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.
Read the full AMA on /r/AndroidDev
The post Android Q AMA Summary: Android R Screenshot changes, Desktop mode clarification, Time-based Dark mode, and more appeared first on xda-developers.
0 comments:
Post a Comment