Here’s Everything Important We Learned from the Android Nougat Dev AMA (INDEXED)

Here’s Everything Important We Learned from the Android Nougat Dev AMA (INDEXED)

Index of Topics:

    1. Night Mode and Theming (Page 1)
    2. Doze Mode (Page 1)
    3. Material Design (Page 1)
    4. Nougat Password Reset Restrictions (Page 1)
    5. Android Bug Tracker
    6. Programming Languages for Android
    7. APIs and Fragments
    8. Android NDK
    9. Long-Term Android OS Support
    10. Bluetooth Support in the Android Emulator

Android Bug Tracker

Redditor thatguyfromthetv:

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.

Response from AndroidEngTeam:

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.


Programming Languages for Android

Redditor eikaramba:

Thoughts on Kotlin?

Response from AndroidEngTeam:

Anwar: Kotlin is interesting: works well with Java, more concise. JetBrains has done a nice job supporting this on android. But no plans to officially support anything new.

Adam: I don’t think we have any plans to break what already works there, but we don’t have plans to have a second, idiomatic-Kotlin version of the whole framework API surface area either. That would be a big duplication of effort when Kotlin already interacts with the existing framework setup well.

Redditor JakeWharton:

API 24 brought partial introduction of Java 8 types and methods. There are highly noticeable omissions from this addition such as java.time.* (JSR 310), java.lang.invoke.*, and convenience methods on String (like join). There also continues to be an absence of types and methods from Java 7 like java.nio.path.*.

As Android’s standard library deviates further from properly mirroring the JDK, what are the views of the platform team with regard to these omissions? Are you concerned about the growing difficulty of the use and development of non-Android-specific libraries moving forward (whether they’re pure-Java or want to target both the JVM and Android)?

Response from AndroidEngTeam:

Anwar: We plan to support more of the Java 8 programming language spec in future releases. 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.

Redditor mastroDani:

Java is a good programming language but it’s age is starting to feel, a modern language would make the development easier and faster. The community is creating many unofficial language supports for developing in Android: kotlin, groovy, scala, just to name a few. This shows there’s a request for it. However choosing one of those language comes with some level of risk or unexpected side effects because of its unofficial support. Is any of those language gonna become officially supported? Or is there any plan to move from Java to something else?

Response from AndroidEngTeam:

Anwar: 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?


APIs and Fragments

Redditor infinitesimus:

Are there plans to improve/streamline handling of media functions like getting an image from the user?

Most code bases I’ve seen have all sorts of workarounds for different api levels to get an image, video, take picture, get audio, etc and it feels rather clunky and leads to a lot of code rewriting

Response from AndroidEngTeam:

Rachad: We feel your pain. There was a lot of API churn introduced over the year as we worked to significantly improve the platform’s capability and performance. In some cases we provide open source libraries like ExoPlayer to make it easy for developers to certain things such as playing back videos across multiple Android version without any Android version of device specific hacks. In other cases we introduced new APIs that provide access to way more advanced features to developers such as MediaCodec or Camera2. In these cases the new APIs are a net benefit to developers.

Redditor infinitesimus:

Fragments are excellent in theory but in practice, seem to cause a lot of headache. In my experience, I find that they are rarely reused in apps and most people just treat a fragment as a screen – making the rather complicated life cycle management more of a stumbling block. Are there plans to perhaps replace them with the concept of screens with are strictly devoid of life cycle knowledge and business logic?

Response from AndroidEngTeam:

Adam: regarding fragments, we’ve got an ongoing project to improve the fragment API, some of which is now part of the API 24 SDK and support libs. It’s pretty difficult to write a correctly behaving app completely ignoring lifecycle, if you’re handling lifecycle correctly then other solutions start looking a lot like fragments anyway. But we’re looking at building something higher level that will help reduce the need to think about it as frequently; the leanback library in particular has been pretty well received for the areas it covers.


Android NDK

Redditor pjmlp:

Thanks for the nice work on the platform, but even with Android Studio 2.2 and Android N, we NDK users tend to feel somehow neglected.

Hence why my set of questions is mainly focused on the NDK.

  • Are there any plans to improve the editing and debugging experience for GLSL and Renderscript?

  • Are there any plans to improve the NDK usability, get access to more platform APIs specially access to libraries like e.g. Skia and libpng, currently hidden behind JNI?

  • How are the progress to make the Gradle plugin for NDK builds achieve the same performance and resource consumption that Ant + ndk-build enjoy?

  • Will Vulkan continue to be only accessible via the NDK without any official Java API?

  • GCC has been deprecated yet clang doesn’t cover all the same features, as some bug reports already mention, what is the plan here going forward?

Response from AndroidEngTeam:

Anwar:

  • Renderscript debug: Renderscript debugging is something we’ve been working on for a bit (you can see progress in AOSP), so you can anticipate support coming soon.

  • NDK support: NDK has been improving pretty significantly over the past few years. For example, we’ve massively improved posix and C++ 11/14 compatibility. We’ve also added media APIs to the NDK. Let us know what the top priorities are for exposurev3r of new apis and we’ll take a look. Note that we require a fairly stable API before we’ll considering adding it to NDK.

  • Clang/LLVM vs. GCC: We are continuing to push for feature parity in Clang/LLVM where there are gaps with GCC.

  • Re: GLSL, Romain Guys says “Not at this point. There is an IntelliJ plugin for GLSL that works in Android Studio/CLion. I use it myself all the time.”

Chet: Vulkan & NDK: Vulkan is a very low-level API that is best used at the low level of the NDK – there are currently no plans to make it available elsewhere.


Long-Term Android OS Support

Redditor muerl:

What is the point of non support UI components anymore?

I realize that before Lollipop the idea was to use, for example, SupportFragments until the userbase of your app was advanced enough to use “Real” fragments. However, post Lollipop and with the introduction of the Design Library google is now building elaborate User Elements using the support library as a base.

Flash forward a year from now, and API 19 useage is where API 17 useage is now, many people will be thinking about setting 21 as the base level, but they are still going to be forced to use ViewCompat for example because they have dependencies on the Design Library.

The feeling I have had about the Design Library was that it was meant to be a collection of reusable elements reflecting Material Design, being the tool that Google expects developers to use replicate the trickier elements of Material Design, but it is going to tied to the Support UI Stack exclusively.

Response from AndroidEngTeam:

Alan: Support library is still necessary on API 21+, see this thread from a month ago. We’re dropping support for older releases on a rolling basis, starting with API < 9 for our upcoming feature release, but we’re still committed to supporting the long tail of platforms with >1% of users.


Bluetooth Support in the Android Emulator

Redditor sonorangoose:

Any news on the emulator supporting Bluetooth? It was mentioned on the official Android Blog back in April 2012, but I haven’t seen any progress in this area:

http://android-developers.blogspot.com/2012/04/faster-emulator-with-better-hardware.html

Response from AndroidEngTeam:

Jamal: We are continuing to add new features to the emulator. For Bluetooth Support in Emulator please vote for the feature request in the AOSP bug tracker (https://code.google.com/p/android/issues/detail?id=56608 ).


Follow our Portal for similar articles in the future. We hope to bring you more content that will pique the interest of regular users as well as developers.

Pages: 1 2

Discuss This Story

Want more posts like this delivered to your inbox? Enter your email to be subscribed to our newsletter.

READ THIS NEXT