News

Google Releases Final Android Nougat Preview, Answers User Questions

• By David Ramel
• July 19, 2016

Google has released the final developer preview of its next mobile OS, Android 7.0 Nougat, in preparation of the final product scheduled to launch "later this summer." The Android engineering team also answered readers' questions in a Reddit "ask me anything" event today.

Considering that fall starts on Sept. 22, there are about 65 days left for the Nougat launch to happen, during which time Developer Preview 5 will be the last bits that developers get to play around with in advance.

Android exec Dave Burke said Preview 5 builds upon the final APIs included in the previous developer release, adding near-final system updates for all supported preview devices.

Specifically, the final preview includes:

• System images for Nexus and other preview devices.
• An emulator that you can use for doing the final testing of your apps to make sure they're ready.
• The final N APIs (API level 24) and latest system behaviors and UI.
• The latest bug fixes and optimizations across the system and in preinstalled apps.

"Working with this latest Developer Preview, you should make sure your app handles all of the system behavior changes in Android N, like Doze on the Go, background optimizations, screen zoom, permissions changes and more," Burke said in a blog post yesterday. "Plus, you can take advantage of new developer features in Android N such as Multi-window support, Direct Reply and other notifications enhancements, Direct boot, new emojis and more."

Today's Reddit Ask Me Anything with Android Engineering Team
The Android dev team shared more information on the new OS during an "ask me anything" (AMA) event held today on the programming section of the Reddit social site.

One early question asked if the team was going to pay more attention to the public Android bug tracker, citing some bugs listed in that tool that have been open for more than a year, "not getting much traction [and] forcing developers to extend support library classes and add workarounds."

"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)," AndroidEngTeam member Anwar Ghuloum (engineering director for Android Core Platform) replied in part. "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.)"

Android dev Alan Viverette, technical lead for the support library, also weighed in on the bug issue. "We've been prioritizing fixing new issues for support library, since we want to avoid breaking features between updates and we want to ensure new features aren't broken to begin with," he said. Due to the sheer volume of existing issues it's taking a long time to work our way back, but heavily-starred issues with clear issue reports (sample projects highly recommended) help greatly."

Answers to other questions indicated camera functionality is going to be improved "in the not too distant future" and -- in response to what are team members' favorite Android apps -- "Is there an acceptable answer at this point outside of Pokemon Go?" (from Ghuloum).

Ghuloum also nixed the ideas of support for reactive programming and for building Android apps with Apple's new Swift language ("Nope, not happening") or, for that matter, any other language (Kotlin, Go, Groovy and Scala were mentioned in posts from multiple readers): "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."

Speaking of Java, the AndroidEngTeam addressed some noticeable support omissions from the partial introduction of Java 8 types and methods in API 24, such as java.time.* java.lang.invoke.* and others.

"We plan to support more of the Java 8 programming language spec in future releases," Ghuloum replied. "We have to prioritize what we spend our time on as we often have to optimize these implementations quite a bit for mobile, so these sometime roll out over multiple releases. In general, we're shortening the lag between platform support for new language spec."

Another Java-related question that received a lot of attention from AndroidEngTeam concerned separate updates. The question read:

"In regards to Android updates is there a way to cleanly separate the Java portion from native so that Google could deliver updates to the Java portions? For instance when UI bugs get fixed we either have to work around the issue for older platforms or hope that the fix is exposed in the Support Libraries. Why can't just the Java portion of the Android Framework be updated and shipped to phones?"

Replies included:

Adam [Powell, TLM on UI toolkit/framework]: this is always a set of tradeoffs. On one hand this would be really great for some things, on the other, devices like the Galaxy Note would have been a lot harder to get released if they couldn't make changes to standard widgets and views to support new hardware that wasn't part of AOSP [Android Open Source Project] yet.

Anwar: It's a neat idea in principle, but there are some tricky things that would need to happen around ensuring stable APIs and ABIs across OEM devices, kernel versions, etc. ... and ensuring proper hooks for customization.

Dianne [Hackborn: manager of the Android framework team]: The issue isn't really a Java vs. native division, but open-source vs. closed source. Google can update any closed source components it provides (such as various applications, GmsCore, more recently WebView). However, all open-source components are by their nature not updatable because Google has no control over those pieces that actually ship on a device. For example, an OEM may make modifications to the view hierarchy (Java code) to support stylus input on their device, something that plain AOSP has traditionally not had complete support for. This customizability has been a great strength of Android, as it has allowed OEMs to do many interesting things without being dependent on support being directly in AOSP.

The subject of Android animations also came up repeatedly. One participant asked if there were plans for improving the animation APIs, for example, with AnimatorSet().reverse(), AnimatorSet().getCurrentPlayTime() and AnimatorSet().setCurrentPlayTime(long playTime).

"We do intend to keep improving the animation APIs and capabilities, and these specific suggestions are under consideration," AndroidEngTeam member Chet Haase, lead/manager of the UI Toolkit team, replied. "Implementing seeking and reversing for animation groups is deceptively tricky (which explains why they weren't implemented to begin with)."

While the AMA is now closed for further questions, Reddit said the Android engineering team will be catching up on answering existing questions over the next couple of days.

Other AMA questions featured in today's post that were answered concerned improving documentation, reducing fragmentation, working with Material Design and other topics, including one on the future of Android:

Q: What's the future of Android look like, 3-5 years down the road?

A (from Powell): We'll probably be at a Q, R or S release by then ;)