With the launch of Android Nougat’s final developer preview yesterday, the Android Development team has jumped on to the /r/AndroidDev subreddit to answer questions from the community. There’s a lot to digest in there, a lot above my technical knowledge, but from a general point of view there was some interesting stuff in there.
Taking part in the AMA was a veritable who’s who of Android development including Dianne Hackborn, Manager of the Android framework team, Anwar Ghuloum, Engineering Director for Android Core Platform, Chet Haase, Lead/Manager of the UI Toolkit team, Rachad Alao, Manager of Android Media framework team and a lot more.
The team answered a lot of questions, so definitely take a look through the entire thread. I’ve picked out a few interesting one though, so here goes:
Night Mode
Will we see night mode in the official release of nougat? If no, please explain why. Its such a brilliant feature. At least leave it hidden as a bonus feature if you don’t think it’s ready for everyone. Thanks!
Alan: 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.
OEM’s implementing Nougat on their devices
This was a question from Krzysztof_Bryk yesterday: Hey! Do You know how main OEMs are doing with adapting Nougat code? Anything You can share? ? Cheers!
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.
Google Camera
This is a question from m4au312 yesterday: the google camera really need some work. Especially when rotating the device from portrait to landscape (or reverse) the viewfinder become very laggy. the camera app should always stay in one orientation, then make in app rotation for the camera ui because the system rotation just not fast enough. and there are a lot of OEMs’ camera app do the same thing and the rotation is very smooth. pleas fix it thank you.
Anwar: We’ve been working on this and I think you’ll be pleased with what you see in the not too distant future.
Swift Support
Can you say anything about the rumours concerning official Swift-support for Android apps? (Probably not, but worth a try)
Anwar: Nope, not happening.
Doze
What are the plans for Doze going forward? Will there be any plans for using more of a light touch instead of using the sledgehammer that is currently used?
Also, to wake from Doze currently, it takes messages sent from GCM. Are there any plans to decouple this from Google services, for those who do not want to or cannot use Google servers to relay their messages?
Adam: Expect the sledgehammer to get bigger, not smaller. 🙂
Paul: But seriously, why do you want a light touch? We’re trying to make it save as much battery as possible without breaking any use cases.
Dianne: Apps that have special requirements to bypass (most) doze restrictions can do that by being on the “disable battery optimizations” list. The system is designed around discouraging apps from being on that list, since each of those apps is another opportunity to deeply harm the user’s battery life. For any app running on a device with Google Play services, we very much want them to be using GCM to wake up the device since this is generally much more power efficient, and for that reason we will continue to push in the direction of apps getting on that rather than relying on their own implementation.
Android TV
Android TV What is the status of Android TV? I developed a handful of applications for clients using it, but then all of the hardware seemed to vanish from the marketplace. A nexus player is more or less non-existent at this point. Will there be new hardware to replace it in the future or is it more likely to be integrated into new TV hardware going forward?
Rachad (Android TV specific): Android TV is doing well in the market with million of devices already deployed (Sony Bravia TVs, Nvidia Shield TV, etc.) and many more to be shipped. In terms of category TVs and operator STBs are leading the way however several new Over The Top (OTT) streaming devices are on their way including Xiaomi’s Mi Box.
Instant Apps
Any update on Instant Apps availability? There hasn’t been any news about it since I/O.
Sorry. Nothing to share at this time. Stay tuned!.
Bug Tracking and Squashing<
This was a question from thatguyfromthetv yesterday: Are there plans to start paying closer attention to the public Android bug tracker? There are bugs in support library that have been open for over a year e.g. [1] [2] [3] and they are not getting much traction forcing developers to extend support library classes and add workarounds. To convince yourself search for ViewPager in GitHub.
Anwar: 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.)
Alan: 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. 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.
The future of Android…/s
What’s the future of Android look like, 3-5 years down the road?
Adam: We’ll probably be at a Q, R, or S release by then 😉
As I said above, the thread is pretty big, with 421 comments, but you can sift through some of the more technical answers if you’re that way inclined. Check it out over on /r/AndroidDev
