Here we go again
It feels like Android N (Nougat) just hit the mainstream but Google is already pushing the next version, Android O to the developer masses. Yesterday, the first developer preview saw the light of day with quite a few exciting announcements. Following the news and comments around the Internet, the consumer audience seems to be especially pleased about the battery life improvements and better notification handling via Notification Channels. We’re still a long way from seeing an official release but starting from today, developers can download the preview on the newer Nexus and Pixel phones. The final release is scheduled for Q3, preceded by four developer previews.
It’ll still take some time to find out what the ‘O’ character in the version name stands for. Looking at the history of all previous Android versions, it’ll very likely be a name of a dessert (Marshmallow, Nougat, Lollipop, Kit Kat etc.) but the logo sure looks a lot like an omelette. You heard it here first. On the right, you’ll see an annotated version of the official logo.
Jokes aside, to get your mouth watering even more, here’s the list of the biggest new features:
- Background execution limits
- Background location limits
- Notification channels
- Autofill framework
- Adaptive icons
- Autosizing TextViews
- Pinning Shortcuts/Widgets
- Fonts in XML
- WebView API improvements
- Media Player enhancements
- Wi-Fi Aware
- Android in the Enterprise
For the last couple of years, Android has been fighting to get closer to the battery life of its biggest competitor, iOS. Apple has it way easier because they have total control over the hardware, while Android needs to account for thousands of different devices with different processor architectures, features and custom version of the operating system. While iOS can optimize its code on a very low level to perform perfectly on a small set of CPU’s they support, their lead is narrowing.
Unlike iOS, Android supports true multitasking which means that there might be a few applications running at the same time, putting strain on the CPU, RAM and other components resulting in a faster drainage of the battery. In Android O, there will be new limitations imposed on the applications that execute code or use the location in the background. The exact details concerning both background service and broadcast limitations are written down in detail in the official Android documentation. It’s worth noting that most of these changes only concern applications that target the API level 26. Lower levels are not affected.
Regardless of the application’s target API level, Android O will limit the frequency of location updates. As a starting point, only a few updates per hour are allowed. This limitation only affects app’s that are in the background; foreground applications will have the same access to location updates as before. To read more about the limits and how to be prepared, read more here.
Notifications are about to receive quite an overhaul. A single app can have a separate notification channel for each distinct type of notification they need to send. In turn, users can make per-channel notifications to the following characteristics
- Show on lockscreen
- Override do not disturb
From now on, individual notifications can’t have a unique importance, it’s defined on the notification channel level on creation time. Read more about the changes here.
Most modern web browsers implement some sort of autofill functionality for web forms. On a mobile phone, this feature is even more important since filling important data like credit card numbers or emails is a time consuming and error-prone job on the small touch screen keyboard. Until now, Android app developers haven’t had access to any sort of autofill functionality but Android O is about to change that.
An app can either serve as an autofill service or use a service provided by another app. Existing applications consisting of standard views will work out of the box but there are a few steps that can be taken to make sure that the app is optimized to fully utilize the framework. Learn more about the feature and the known issues here.
Custom launchers are still a big deal to millions of Android users because of the limitations in vanilla Android. However, Google is slowly adding more customization possibilities to the end users. Adaptive icons let the developers define two separate icon layers; background and foreground. The system will then provide the mask to the icon and possibly animate it using a parallax or pulsate visual effect. Without further ado, here are some animations showcasing the feature (from the documentation).
Android O introduces a possibility to “instruct a TextView to let the size of the text expand or contract automatically to fill its layout based on the TextView’s characteristics and boundaries” [Android documentation]. This will allow developers a lot better control over how text acts on different screen sizes and densities. No more hacks that dive deep into the layout mechanisms and drawing of the native TextView control. Autosizing can be set on code or XML using Granularity or Preset Sizes.
Granularity allows developers specify minimum and maximum sizes coupled with the step granularity that defines how much the text increases or decreases in one step. Preset sizes is simply a list of preset sizes that the TextView will translate to once it can fit in the container.
Pinning Shortcuts and Widgets
iOS users are familiar with the Home screen quick actions that show a context menu when the user holds their finger down on the app icon. Android introduced a similar technique called App Shortcuts on API level 25. Pinned shortcuts are similar but they appear on the launcher as separate icons as seen on the image on the right (courtesy of Google). Users can also pin app widgets that give users access to specific tasks in the application.
Fonts in XML
Fonts as resources. About time, right! Fonts can be bundled as resources by adding them to the res/font/ folder. After compilation, the fonts are available in the R file and can be referenced using the new resource type, font:
Read more about working with fonts and how to retrieve system fonts here.
WebView API Improvements
Android O provides several improvements to the WebView control’s API to improve the stability and security of the applications:
- Version API
- Google Safe Browsing API
- Termination Handle API
- Renderer Importance API
Version API lets developers choose the version of the WebView package to use inside the application. While this feature won’t likely be useful when supplying the end product, it can help developers analyze errors in specific package versions.
Google Safe Browsing API might be familiar to the users of the Chrome browser. When the user is navigating to a site that is dangerous in one way or another, the WebView shows a warning. Opting in to the feature only requires adding one <meta-data> element to the AppManifest.xml file.
<meta-data android:name="android.webkit.WebView.EnableSafeBrowsing" android:value="true" />
Termination Handle API ensures that the app itself doesn’t crash if the WebView control loses the renderer process due to a crash or system killing it to save memory. Even though the app keeps running after a crash, the WebView object cannot be reused. Here’s an example on how to use the API.
Renderer Importance API should work hand in hand with the Termination Handle API. With it, developers can set the priority for the renderer associated with a WebView. If a low priority is set to the WebView, the system is more likely to kill the process in a low-memory situation.
Media Player enhancements
The MediaPlayer control is about to get improvements to controlling the buffering behavior and seeking to a frame. On top of that, DRM-protected material can now be played by partially providing the functionality of MediaDrm introduced in API level 18. The current implementation can handle Widevine (by Google) protected local and remote/streaming media files. If you’re interested in learning more about the Widevine DRM technology, check out the architectural overview document here.
Android O introduces a new BufferingParams object that helps the developers get a better control over MediaPlayer’s buffering. The player will use watermarks to make sure that the control initially buffers enough and keeps the buffer filled between high and low marks. Read more about the buffering changes here.
Wi-Fi Aware (aka Neighbor Awareness Networking or NAN) enables devices to discover and directly connect to each other without any other connectivity in between. The system service forms clusters of devices and the apps in turn, talk to the service to discover other devices and form connections to them.
After the connection is established, apps can reliably share data between each other. According to Google, the “connections are more reliable than Wi-Fi P2P connections and support higher throughput rates across longer distances than Bluetooth connections”.
To learn how to do the initial setup all the way to sending a message, refer to the Android documentation on the topic.
Android in the Enterprise
It’s become clear that Google is looking to get enterprise users into the Android ecosystem. With the current BYOD (bring your own device) trend it’s important that the enterprises can effectively manage access, content and even applications on the employees’ devices. For instance, the Corporate Owned Managed Profile (COMP) makes it possible for the device owner to have a separate profile managed by the enterprise which in turn allows apps and policies to be separate. On top of that, there are many other improvements and new features listed and explained here.