Google announces the Android O Developer Preview



  • A background processing lockdown, picture-in-picture for phones, and a faster runtime.

    BY RON AMADEO

    0_1490150079894_1.jpg

    Almost exactly a year after the Android N Developer Preview launched, Google is unleashing a developer preview of the next major version of Android, "Android O." We haven't tried it yet (images should be dropping any minute now), and the heavy developer documentation is still on lockdown, but we do have a big list of new features to go over.

    This first developer preview is apparently not going to be super stable. Google's blog post notes that "it's early days, there are more features coming, and there's still plenty of stabilization and performance work ahead of us. But it's booting :)."

    Because of the early status, this first version of Android O won't be rolling out to the Android Beta program, which offers handy in-place OTA upgrades. Instead Google will be kicking it old school with images for the Nexus 5X, 6P, Player, and the Pixel, Pixel XL, and Pixel C. There's a Wear 2.0 version of Android O, but it's only available via the emulator. There's also a new version of the SDK, Android Studio 2.4, for developers interested in trying out the new APIs.

    Also remember there are two main parts to Android: the open source "AOSP" part and the closed-source "Google" part. Today we're only hearing about the open source parts, in contrast to day one of the Android N Developer Preview, where we only heard about AOSP features like split screen, redesigned notifications, and improved power savings. When it grew into the fully realized version of Nougat on the Google Pixel, we got headlining "Google" features like the Google Assistant. As usual Google says, "Over the course of the next several months, we'll be releasing updated developer previews, and we'll be doing a deep dive on all things Android at Google I/O in May." Now let's dive into some features!

    Background processing lockdown

    0_1490150293940_2.png

    0_1490150309264_3.png

    0_1490150315589_4.png

    0_1490150323063_5.png

    Google's blog post says Android O "puts a big priority on improving a user's battery life and the device's interactive performance." Google plans to do this by adding "automatic limits" to what apps can do in the background in "three main areas: implicit broadcasts, background services, and location updates."

    "Implicit broadcasts" are device-wide announcements that any app can listen to. In older versions of Android, these were things like a "connectivity change" from LTE to Wi-Fi or a "new picture" alert. Any app can sign up to receive these broadcasts and could wake up the second they happened, which is not a great idea for performance. For instance, when you take a new picture, Google Photos immediately starts up in the background and uploads the picture, and so can Dropbox. A picture editing app can also start up and add it to its photo index. Take a second picture, and all these apps are filling up your RAM and slowing down the phone.

    We don't have the documentation yet, but Google warned app developers at I/O 2016 that a background-processing lockdown was coming. Google identified apps' aggressive use of implicit broadcasts as a big reason for battery drain and sluggish performance, and it even shut down the "connection change" and "new picture" alerts in Android 7.0 Nougat. The recommended replacement for these background jobs was "Job Scheduler," an API introduced in Android 5.0 Lollipop. Job Scheduler is a "lazier" way to do background processing. Apps sign up for a background job, which would happen at some point in the future. Job Scheduler batches up background processing requests into one big slice of "background processing time," which preferably happens when the phone is idle, or better yet, plugged in. Job Scheduler is like a traffic cop for background processing, resulting in a phone that wakes up less, sleeps more, and saves more battery.

    During its background processing talk at I/O, Google showed off a "vision" for how background processing would work in a "future release" of Android. All implicit broadcasts were shut off, and apps would have to totally rely on Job Scheduler. Doing this to everything would break a lot of apps, so the proposed change would happen only for apps that "target" the new release. "Targeting" a release of Android means an app is aware of Android features up to that release and would be signing up for the new APIs and background restrictions. We'll have to dive into the documentation once it goes up, but it seems like that "future release" Google talked about at I/O is Android O.

    Adaptive icons

    0_1490150384399_NB_Icon_Mask_Shapes_Ext_02.gif

    Pixel devices use circular icons, Samsung devices use a squircle, and numerous Chinese companies try to emulate Apple's rounded rectangle icons, so what's a third-party app developer to do? The new "Adaptive icons" feature will let developers pick a background image, which each individual Android skin can then cut out to fit the system design.

    The idea is to have your unique icon in the center of a variable shape, with a background image that can be cut several different ways. This new type of icon will work pretty much everywhere you see an icon—on the launcher, shortcuts, settings sharing dialogs, and the overview screen—and system animation will be correctly applied to the variable shape.

    Picture-in-picture on phones and tablets

    One of the goals in Android 7.0 Nougat was to standardize a lot of the windowing shenanigans OEMs had been pulling off in their Android skins. The development of a resizable app framework led to split-screen mode on phones and tablets, picture-in-picture mode on TVs, and a multiwindow mode that hasn't been used on any Google device but is there for OEMs like Samsung that want to implement it.

    Multiwindow mode and split screen are not necessarily enough for phones and tablets, though. A lot of OEMs and app developers try to implement a phone picture-in-picture mode or a floating video window with all sorts of hacks. Now in Android O, picture-in-picture on phones is something that will be officially supported. Apps will be able to spawn a floating video feed with custom commands like "Play" and "Pause." It would be great if this worked for YouTube, and hopefully Google won't make it part of the "YouTube Red" subscription service

    Better keyboard navigation

    0_1490150461578_6.jpg

    If the Pixel C is to be believed, the future of Android tablets involves being productivity-focused keyboard machines. The problem is Android has pretty terrible hardware keyboard support, and Google plans to make that a bit better in Android O. Google says it is "focused on building a more reliable, predictable model for "arrow" and "tab" navigation."

    Better tabbing will be a welcome improvement, but the Pixel C with Android 7.0 still has a ton of keyboarding issues beyond just navigation. Android is designed around a software keyboard, and when you take that away and replace it with a hardware one, a lot of issues pop up. You would expect to be able to open up an app and start typing on your hardware keyboard, but no app really does "default typing focus" correctly, because that would make a software keyboard pop up on most devices. So you always have to do an extra tap on the input box you want. Maybe now you'll be able to tab over to a box, but that's still clunkier than a real keyboard-and-mouse OS like Windows, MacOS, or Linux.

    The software keyboard also has auto correct, and many apps (like Gmail) rely on it for spell check. Use a hardware keyboard and suddenly a lot of apps have no spell check at all.

    0_1490150495665_7.png

    I hope phones never get rid of the headphone jack. But if they do, (or even if they don't) it would be nice to have something better than the crusty old Bluetooth A2DP protocol wireless headphones are stuck with today. To help with this, Android O is packing support for some higher-quality wireless audio options.

    Sony has donated its proprietary LDAC codec—a higher-bandwidth, higher-quality alternative to regular Bluetooth—to AOSP, allowing any OEM to implement LDAC on a device for free. Building a set of compatible headphones will most likely still require paying a licensing fee to Sony, but the consumer electronics giant is probably hoping that becomes a more appealing idea to headphone manufacturers once every new Android phone has LDAC onboard. Right now you will only find LDAC headphones from Sony.

    Sony actually got a special shout out from Google in the blog post: "Sony Mobile has contributed more than 30 feature enhancements and 250 bug fixes to Android O." This isn't the first time Sony has dropped big chunks of code into AOSP; the company is also responsible for Android's resource-overlay framework, which powers most of the OEM theme stores you see out there.

    There's also a plug-in architecture in Android O for "high-quality Bluetooth audio codecs," so if an OEM prefers something like Qualcomm's AptX (another proprietary higher-bandwidth/higher-quality audio standard) they can pay a licensing fee and more easily drop it into Android.

    Tons of other features

    Android O's list of features goes on and on.

    Autofill APIs will allow users to select a designated autofill app, "similar to the way they select a keyboard app." This should make password managers work a lot better, without the need for janky copy/paste solutions or hacks to the keyboard framework.

    Notification channels are "app-defined categories for notification content." This will be a way for apps to provide a bunch of notification "channels" that the user can manage. Most developers build this from scratch today. Gmail lets you pick what labels you want notifications from, and a Twitter app lets you decide if you want notifications for retweets, likes, and/or new posts. This will be a more platform-standard way to provide different notification types, putting the "channels" in the regular OS notification settings, rather than buried somewhere in the app.

    Wide-gamut color support for apps will allow imaging apps on devices with wide-gamut color displays to open wide-gamut images with the right color profile. This isn't HDR, which offers more (and less) brightness, but wide-color, which offers more colors.

    Font resources in XML will make fonts a "fully supported resource type" in Android O, allowing developers to add a custom font to an app just as easily as they add images or text. With great power comes great responsibility, developers. Please don't use crazy fonts!

    AAudio API for Pro Audio is yet another swing at low-latency audio on Android. Google says that this new API is "specifically for apps that require high-performance, low-latency audio," and today it's releasing an "early version" to get feedback from developers. Low audio latency is crucial for music-creation apps—you can't play a virtual piano if every key touch has a delay—but there is no silver bullet. Audio latency is something created by the entire stack, the SoC, display, drivers, and OS. So even if Google gets everything right, it will only work on devices specifically designed to minimize latency.

    WebView multiprocessing is now on by default. WebView is basically an embeddable browser window for apps, and in Android N it became part of the Chrome APK and switched to a "beta" multithreaded version. Now it's the default. Developers will get WebView crash handling in Android O, too.

    ART Optimizations: Google says the Android Runtime (ART) is "faster than ever before, with improvements of up to 2x on some application benchmarks." ART is the engine that powers Java apps on Android, so an improvement to ART can automatically make nearly every app better. Google is also promising new Java APIs, like Java.time.

    Original source


You may be interested in..

Log in to reply
 

Looks like your connection to SuperSU Forum-where rooting fans gather was lost, please wait while we try to reconnect.