The Android Engineering Team hosted a Reddit AMA this afternoon to answer technical questions after the release of the fifth and final N Developer Preview. The more developer focused Q&A session discussed some app and Nexus-specific queries, programming languages, and OEMs updating to Nougat.
There was also discussion about removing the Night Mode from the final version of Android N, battery drain, and Material Design. For developers, it is definitely worth reading through the entire thread. Due to the interest, the engineering team will consider doing more AMAs in the future.
On when OEMs will update devices to Android Nougat:
We can’t share who or how many, but we are working with OEMs in parallel with Developer Previews to get their devices updated as soon as possible. [Thread]
On rumors concerning official Swift-support for Android apps:
Nope, not happening. [Thread]
On Java aging compared to other modern languages:
We don’t have any plans to move to a new language. Java has a lot of advantages to it and the versions 8, 9, and 10 have some pretty interesting stuff for developers. We are planning to track more closely in time to the Java language standard. What kind of features are you looking for in a programming language for Android? [Thread]
On the longevity of Material Design:
Adam: if it starts growing mold we’ll need to look at a replacement.
Alan: No, we’d re-grout the areas between the whitespace. I think it would be fine. But seriously, I think there’s plenty of room for Material to continue to grow and adapt. We’ve seen new widgets introduced, specs refined and changed. From a framework perspective, it’s been interesting to figure out how to evolve the spec without breaking the design of existing Material apps.
Chet: One element about Material that might help its longevity is its reliance on plain, white assets that can then be tinted according to theme colors that make sense for the app. This strikes me as a more future-proof approach than some bold, trendy look like, say, birch-wood-grained that is going to look bold and dated soon.
Rachel: All this to say, Material Design isn’t going away anytime soon. The fundamentals – motion, expressing your brand, clean and clear layouts – are good bets for long-lasting behaviors you’d want any app to follow. [Thread]
On battery drain in Android:
Check the other answer about the bug tracker — we do pay attention but it is hard to keep up, and we have a team monitoring it now. In better news, we think the first bug you mentioned is fixed in Nougat. I am aware of the third and fourth issues and someone is looking into it. The difficulty with some of the other reports (as with many battery issues on the tracker) is that modem and wifi issues on other vendors’ hardware will need to be fixed by the manufacturer of the device…though it is unclear what devices are being discussed in each initial report. (Be sure to specify what device and software rev you are using in your bug reports!) [Thread]
On Google Camera viewfinder rotation lag:
We’ve been working on this and I think you’ll be pleased with what you see in the not too distant future. [Thread]
Nexus 9 will not receive support for Vulkan:
9 will not be getting Vulkan drivers, but Pixel C has had them since the second N Developer Preview. [Thread]
On Nexus 6 lag:
We are looking into this. We did notice some jank while scrolling comments that are being loaded for the very first time during Youtube video playback on Nexus 6 running Android M. The jank does seem to improve when forcing GPU composition. Youtube on Android 6.0 uses SurfaceViews for video playback because it consumes less power than using TextureViews. Forcing GPU composition improves comment scrolling smoothness at the cost of power. Stay tuned. [Thread]
On removing the “night mode” (dark theme and screen tinting) from the final version of Android N:
This one has been my pet feature for a while… So there were two “night mode” features in N DP that you might be referring to: dark theme (via -night qualifier) and screen tinting.
The former, dark theme, was a modification to Material that would automatically switch between light and dark variants based on UiModeManager’s night mode setting. Which was awesome, and I know a lot of people really liked seeing a dark theme in Settings; however, in both M and N the dark theme feature had to be reverted because of ecosystem problems. As simple as we tried to make it, implementing dark theme meant doing twice as much design work and twice as much verification that visual styling was implemented correctly. It wasn’t a good allocation of design and engineering resources. In many places, like WebView, it simply wasn’t possible to convert content to a dark theme while preserving the content author’s original intent. Leaving a half-working feature in the platform, where developers would be expected to support it, wasn’t acceptable. So I’ve had to personally kill the feature twice, and ultimately it’s been for the benefit of the platform.
HOWEVER! We were still able to launch dark theme in support library, so apps can still benefit from the super-simple -night qualifier.
The latter, screen tinting, was built on top of the display accessibility APIs introduced in M. This was another “ultimately for the benefit of the platform” issue… The feature needed serious work, both on the low-level graphics driver side to implement tinting efficiently and the high-level TwilightManager side to correctly implement automatic shifts between day and night. It wouldn’t be ready in time for N, and it wasn’t acceptable to leave a half-working feature, so we had to pull it. It have been really rewarding to see positive feedback for the feature, though, and I would love to see it in a future release. [Thread]
On lack of responses to the AOSP issues tracker:
We generally track public bugs pretty closely. Admittedly, it’s been historically difficult to keep up, but over the last couple of major releases, we’ve got a team dedicated to triaging public issues. That doesn’t mean the odd bug doesn’t fall through the cracks. For the three bugs you mentioned, two of them are pretty dated which is probably why they aren’t getting the attention they need and is actively being investigated by the component owner (much more recent). That said, there is a need to prioritize issues and if there are well-known workaround publicly available, that might impact prioritization (not saying that’s the case here). (Note that some teams use the public tracker as their primary issue tracker.) [Thread]