Android Nougat and More
Android Nougat has arrived! It was the earliest developer beta and its new features have been well-covered since last March. Multi-window support is neat, especially with the drag-and-drop functionality, which allows apps to share content across screens. Notifications have been improved. They allow for direct replies inside the notification. Also, they bundle notifications from a single app into one notification which improves user experience. Notification improvements and multi-window support are very visible to the user and have received the lion’s share of attention.
Another great change in Nougat is a focus on accessibility. This is the most accessible Android version ever. Android has long supported scaling up the font for users with impaired vision. Now these users can scale up the whole screen. Android has long supported a tremendous variety of screen sizes so this change doesn’t require much extra effort. However developers should double-check their layouts on screens as small as 320dp since even modestly-sized screens can be scaled into this minimum range now.
Instant apps is a huge change which could herald a drastic difference in how apps are perceived and architected. Currently it’s an invite-only process to become an instant app. It might never make sense for apps with huge amounts of data or sign-in credentials required. However, the promise of playing a clip inside a native app player instead of through a chrome player without the user downloading the actual app is very appealing. I don’t have numbers, but my intuition suggests that requiring a user to download an app through the Play Store decreases app impressions, especially if the user is on cellular data with a limited data plan.
Other changes will never be seen by users. These are developer-facing changes like Vulkan and WebViews running on Chrome. They improve the user experience without the user ever noticing by improving performance and increasing security behind the scenes.
For apps which draw directly to a Surface, like most video players and games, there is a major change to SurfaceView. In the past, animating changes to SurfaceView was an easy way to break an app. The SurfaceView has punched a hole through its window so resizing or translating it will create artifacts on the screen. These are places where the window is still delegating control to the SurfaceView even though the SurfaceView has moved away from that spot. The solution, before N, was to use TextureView when a SurfaceView requires animated changes. SurfaceView can composite its content separately from app content, which requires fewer intermediate copies than TextureView, which is rendered on to the entire screen at once. As a result, SurfaceView is lighter-weight and better for battery performance. Now SurfaceView’s content position updates synchronously with the other app content so now it can be moved without creating artifacts. This is most likely a move to support VR apps on Android, which are huge battery killers and require moving Surfaces rapidly, but it benefits all apps. Apps using TextureView should strongly consider moving to SurfaceView. This is a platform change, so developers must still support backwards compatibility for previous platforms which still require TextureView to animate a Surface. Hopefully the support library will add a class for manipulating Surfaces to bridge the gap.
Another change that users — and possibly even developers — will never notice involves WebViews. Starting in Nougat, Android will leverage Chrome directly to render WebViews. In Marshmallow, WebViews used Chromium, the underlying engine of Chrome. Taking it one step further, now they run directly on the Chrome browser, if it’s available. This is a good change since it will leverage a tested, proven solution for rendering web content that already exists on most devices. Another benefit is that Chrome is outside of the platform so it can be updated like a normal app, instead of with the platform. If a security risk is exposed in Nougat WebViews five years from now, then Google can patch the issue with a new Chrome update instead of relying on users to go get Android O or P devices. It’s a similar logic to the support library; move updates outside of the platform and backwards compatibility will improve for everyone.
There are a couple changes to security which are phenomenal and important. First, apps have to explicitly trust SSL certificates. This helps to prevent man-in-the-middle attacks. Previously, a technically-savvy person could install a certificate and watch secure traffic pass from any Android app to servers. This sort of sniffing is a severe security risk, while at the same time a valuable debugging tool. There is no perfect level of security, but this raises the bar substantially. Developers can still whitelist themselves for debugging purposes. Also, apps can update their configuration to prevent cleartext traffic. This blocks all HTTP traffic to ensure everything the app does is secured.
There are even more goodies in Android Nougat, and many resources on the web to learn more. This overview is a good starting point.
Unfortunately, the reality of the Android platform requires a caveat when talking about platform changes. Some users might not use a Nougat-powered device for a long time. A majority of users won’t use a Nougat device for a year if current adoption rates continue, and nothing suggests they will change soon. This doesn’t mean apps should ignore Nougat or that supporting multi-window is a low priority. It just means that Android developers must always be backwards-compatible first when stepping forward to new Android versions.
Also, sincere thanks to the Support Library team for making backwards compatibility much, much easier and to the platform team for avoiding breaking changes. They might deprecate methods but they rarely remove them. Together they make supporting both Jellybean and Nougat easy.
Speaking of the Support Library, it was updated to 24.2.0 recently.
The Transitions framework seamlessly animates from one view hierarchy to another. To achieve this effect, one could manually animate each View within a ViewGroup out, and animate another set of Views from the next ViewGroup in. Obviously that is a tedious and error prone approach. Transitions is a much better alternative. Until this update it was only available when targeting KitKat or above. Now the Support Library has backported it to Jellybean, which means the majority of apps can support it!
Note: Transitions don’t animate well with SurfaceView and TextureView, due to asynchronous UI updates and ViewOverlay incompatibility, respectively.
Also DiffUtil has arrived! When changing the data for a RecyclerView, there is typically a noticeable hiccup when all the data leaves, then all the data returns. Sometimes this moves the interface unexpectedly when the data refreshes. There are ways around this but most involve significant overhead to implement and maintain. The new DiffUtil calculates the minimum difference between two collections, namely the collection currently shown by the RecyclerView and the collection which should be shown next by the RecyclerView. It uses an optimized difference algorithm to find the minimum changes between the two collections. After it also accounts for items that have moved, the changes can be dispatched to the RecyclerView to consume.
Note: for large data sets, DiffUtil operations should run on a background thread.
But wait, there’s more! TextInputLayout has a password-visibility toggle built in, which matches material design. CoordinatorLayout is more flexible to allow inset views which aren’t a FloatingActionButton. There’s improved Custom Tab and <vector> support. The full list is in the Support Library Revision History.
Finally, when talking about Support Library in 2016, it’s necessary to mention ConstraintLayout. It’s still in alpha. There’s tremendous coverage of the new layout. Check out Dave Smith’s series “ConstraintLayout, Inside and Out.”
More than phones and tablets
This is part of the overall Android change to multi-window experiences, but a specific implementation for Android TV. Picture-in-picture (PIP) pins a video activity into a corner of the screen so a user can multitask within an app or between apps. The UI considerations will be roughly the same as playing video when visible behind the home screen. There should only be video content in the window without controls or calls to action. Based on previous Android TV work, I expect the trickiest piece of PIP support will be handling focus. Even if your app won’t support PIP, other apps will, and they can appear over your content, which requires careful UI consideration. The PIP content will always appear in one of the four corners. Branding that always needs to be visible on the screen should shift away from the corners. Finally, it’s worth noting that while Android updates tend to be overlooked since the adoption rate is so low, the Android TV adoption rate is very high since most of the hardware manufacturers have worked closely with Google.
Wear 2.0 is a major change to Google’s smartwatch platform. Unfortunately, early adopters of Android Wear will have to buy a new watch. However, if you’re enjoying your current Android Wear smartwatch, you’ll love the changes. Just like in Nougat, notifications are improved with inline responses, which give a scaled down app experience and context, which allows for conversational notifications
The big headliner is standalone apps. Being able to stay connected without your phone makes Wear 2.0 a game changer. There are a few implications to note when developing Wear 2.0 standalone apps. The app has to be able to handle its own authorization and authentication. Also, instead of using the existing Notification Bridge to transmit messages through to the app, now Firebase Cloud Messaging, formerly GCM, can transmit directly to the watch. In addition, developers can remove the watch code from the mobile app’s APK to reduce its size, since the watch can download apps directly from the store.
Wear 2.0 also provides better fitness support by integrating with Google Fit and real time Gym Activity Recognition, which means your watch recognizes your jogging motion and starts your run tracking app automatically. To improve user experience, developers can now share data through Google Fit to sync goal tracking apps with fitness tracking apps, or MapMyRide with the Fitbit app.
The watch face has also received a significant update. Developers can now create custom complications, which are small snippets of info on the watch face itself. Examples of possible complications include a weather notification, stock tracker, and calorie counter. This truly makes your app’s info glanceable since it sits directly on the face of the watch. Since watch faces come in endless varieties, the watch face gets to dictate colors, fonts, and visual style. When creating a complication, the developer should consider it as a mere data provider to dictate content like text, image, or numbers.
Android has reached maturity as a platform. These updates probably won’t have people running to the store for a new phone, but they’re important nonetheless, especially for developers. There’s a lot of Android changes to get excited about in 2016, and we’re barely halfway through the year. Nexus Marlin and Sailfish devices should launch in October with Android Nougat 7.1, and ConstraintLayout might come out of alpha soon.