Android 5.0 Lollipop, thoroughly reviewed

"Overview"—native and Web apps in a single list

"Recent Apps" has been completely revamped in Lollipop and is now called "Overview." The new design borrows from mobile Chrome's tab switcher, using a cascade of overlapping, full-screen thumbnails. In fact, Chrome's tab switcher is gone in Android 5.0. Chrome no longer has a tab button or a gesture to switch tabs; the system-level Overview screen completely replaces it.

In Lollipop, applications can add more than one entry to the Overview list. The biggest user of this functionality is Chrome, which creates an Overview entry for every single tab. This elevates Web apps to the same level as native apps—they're just mixed in with your other tasks.

Other apps make use of this, too. Settings will spawn multiple pages when accessed in multiple ways. For instance, opening the settings icon will spawn one page; leaving this page and accessing the Wi-Fi page from the quick settings panel will then spawn a second page. In older versions of Android, this second page would have taken over the old settings task—or not created a Recent Apps entry at all.

Google Drive will push each document out to the Overview, too, making it a snap to switch between documents. Hopefully, more apps will be updated to take advantage of Overview; we'd love to see Hangouts push each conversation out to Overview, and Gmail/Inbox could add each opened e-mail to the list.

The new Overview behavior takes Android from app-centric multitasking to document-centric multitasking; what matters is what you were last working on, not what app you were using. And if you're a heavy user of a certain app, having it push multiple entries out to the Overview will make zipping around the interface a lot faster.

Overview slaps a title bar on top of every full-screen thumbnail, and Android 5.0-aware apps can apply a color to this bar, making it easier to identify. Apps can still be swiped away to close them, but users can also click a much more obvious "X" button in the top right corner of every thumbnail. Google also added a search bar to the top of this screen. (Again, Google loves search.)

Multiple Chrome tabs, which you can see listed in the center picture (above), have a few special behaviors. Each entry gets a title bar and the "app icon" is a black square containing the first letter of the website. It's rather bland and unfinished looking; displaying or pulling a prominent color from the favicon would make tabs much easier to identify. In Chrome 39 (currently in beta), websites can add a meta tag to both color the gray title bar and add a high resolution favicon. Next, we just need the entire Internet to do that.

Overview has a tab grouping feature, which makes pages opened from the same tab group together. You can see this in the center picture (above) where the front three entries—the Ars Technica home page and articles about the Retina iMac and Halo—are all grouped. The title bars in a group all stick together as a single block, and switching to one tab in the group moves the entire group to the front of the Overview list.

Overview's history now goes on seemingly forever with something like 100 entries, and the list even persists after a reboot.

The one disappointing change to Overview is that you can no longer long-press on an entry to jump into the App Info screen. It used to be a snap to force-close or uninstall something from the Overview screen, but now you're stuck hunting down the app icon or digging through the settings.

Update: As Android Police points out, it is possible to long-press on an app icon in the overview and jump to the App Info screen. There is a bizarre requirement to make it work though: you just have to enable "developer options" in the settings.

The new Overview behavior goes on to fix some long standing bugs with the app listings, particularly around apps launching from other apps. For instance, pressing the Share button from a Play Store listing and picking "Gmail" as the share method will open the Gmail compose window with a link to the app listing. Doing this on the old Recent Apps screen would give you a really confusing entry, listing the app as the "Play Store" but showing a thumbnail from Gmail while launching Gmail.

Lollipop will correctly spawn two Overview entries, one for the Play Store and one for Gmail. Overview even correctly makes entries for Settings pages accessed from a shortcut. Before, if you opened a settings page from the Quick Settings shortcuts or a home screen shortcut, no Recent Apps entry was produced.

In the security settings, users can turn on "Screen pinning"—basically a "Kiosk mode" for apps. When screen pinning is enabled, a pin icon appears in the bottom left corner of the most recent listing in Overview. Pressing it will lock the device to that app, dim the status bar, and disable the navigation button. The only way to get out is to press the Back and Overview button at the same time. It's not meant to be secure, and pressing any of the navigation buttons will pop up a message telling the user the key combination to disable screen pinning. So if the person you're locking out can read, defeating this should be no problem.

This seems to be more a demo than anything else. The developer docs say that "Device owner" apps (a new type of app class above "device administrator") will be able to programmatically enable screen pinning, which would then lack the back+overview exit shortcut. Such apps can apparently create a more secure version of screen pinning that would actually work as a public kiosk.

Project Volta

"Project Volta" is another one of Google's concerted, OS-wide efforts to improve a particular aspect of Android. Jelly Bean had "Project Butter," which made Android's UI animations run at 60fps, and in KitKat we got "Project Svelte," which aimed to get the OS running in only 512MB of RAM. In Lollipop we have "Project Volta," which aims to boost Android's battery life.

While ART's benefits apply to most apps without any developer involvement, Volta isn't so automatic. It's an effort that spans system design and new APIs, and it requires that app developers be responsible with the user's battery.

The first step to improving battery life is collecting data. In addition to new battery tracking in Lollipop, Google built a Python script to create the "Battery Historian." The script turns bug report data into an easily parseable power-usage graph. Developers (and Google) can use this new data visualization to see where their apps are sucking down power—and fix them.

When Google first set out to improve Android's battery life, it performed an experiment. Android developers took a Nexus 5, put it in airplane mode, turned the screen off, and measured the standby time. The device, which struggles to last a day with typical usage, lasted a full month like this. The takeaway? Sleeping is good. If you can get everything to just stop doing stuff, you'll have great battery life.

Unfortunately, Android is frequently doing "stuff" in the background, even when the screen is off. Apps wake up the processor and modems to check for updates or to perform housekeeping functions like organizing a database or uploading diagnostic logs. Apps usually do this on a timer, and each app is on its own timer. If you install many apps, your device will be performing background functions a lot.

To cut down on the frequency of individual background tasks, Google created the "JobScheduler" API. This talks to and organizes background tasks from your collection of apps, aiming to batch up background tasks into a single burst. It can even offload some background tasks to times when they are more appropriate.

Before JobScheduler, background tasks that required Internet access would individually wake the device, check for data, fail if there was no Internet access, and set a timer to check again in a few minutes. Instead of that approach, JobScheduler lets apps specify conditions that their task needs (general connectivity, Wi-Fi, plugged into a wall outlet, etc), and it will send an announcement when those conditions are met. It's like the difference between push e-mail and checking for e-mail every five minutes... but with task requirements.

To batch up background tasks, developers can specify a timeframe for a task instead of an exact countdown. A process that needs to wake the device can now tell JobScheduler that it needs to do something in the "next few hours." When JobScheduler has enough background tasks, it will wake the phone up and perform all such tasks at once.

With these new capabilities, Google is asking for a "lazy first" mentality from app developers. Reduce the amount of background tasks, be flexible with the timing of your tasks, and if you can put the task off until the user is plugged in, even better. Apps all need to be individually updated to talk to the JobScheduler, and they need to not be so aggressive about waking up the device. Once that work is done, Google says users can expect a 15 to 20 percent improvement in battery life.

You can see this in action on Lollipop with things like the Play Store. When you plug in your device and are connected to Wi-Fi, then the Play Store will check for app updates and download them. This saves users' battery power and bits on their metered data connections.

The JobScheduler and Battery Historian are the parts of Project Volta that Google has been specific about, but as with past "Projects," Volta has been an all-hands effort.

As we've seen in many OEM skins, Android 5.0 ships with a "Battery Saver" mode that cuts the SoC power and background data to give you a longer runtime. To let you know this is enabled, the status and navigation bar turn traffic-cone-orange. You can set the mode to automatically enable itself at five or 15 percent battery, and it will automatically disable when hooked up to a power source.

Lollipop in Battery Saver mode is still a smartphone, but it's one that won't push anything to your attention. If you want to see e-mail, you have to open the e-mail app. The same goes for Hangouts or anything else that would normally push data.

On the Nexus 6, Lollipop's Battery Saver mode limits the 2.7GHz processor to a steady 730MHz, just barely enough to run the operating system. The 730MHz cap turns the entire phone into a sluggish marathon runner. The UI is mostly normal, but many of the animations are cut, and everything is really slow.

In this mode, scrolling is a janky mess; we turned on the GPU Profiler in the right picture (above) to see just how slow things. Every vertical line above the green horizontal line is "jank" or a dropped animation frame leading to "laggy" scrolling. Smoothness isn't the point of Battery Saver mode, but just know that all performance bets are off with this mode enabled.

The new camera API

Image quality from cameras has always been a rough spot for Android, especially Nexus devices. While everyone uses the same CMOS chips, the real difference in image quality is in the software. Google has seemingly not focused on the camera software stack in the past, putting the burden on OEMs to replace or extend the camera stack if they want a half-decent experience.

In Lollipop, Google is introducing a long awaited camera API revamp called "Camera2." Its headline feature is the ability to optionally capture RAW image files instead of JPGs. The commonly used JPG file format is "lossy," meaning it throws out some of the data that was originally recorded by the camera. Some of this lost data is information that is cut by the exposure range and some of it is lost to compression. In contrast, RAW is a "lossless" format—it records all data from the image sensor and doesn't lose any information from compression.

Just like a film negative, RAW files aren't really a finished picture (hence the name), but they do contain all the data needed to make a picture. To get a picture from a RAW file, it needs to be "developed" in a RAW-capable image editor. Loading a RAW file into an image editor gives the photographer much more control over the white balance, exposure, and other color and luminance settings, but the resulting file sizes are much larger than JPG (about 2-3 times larger). Google isn't using some wacky version of RAW, either; Lollipop supports outputting to Adobe DNG, so your files will play nice with Photoshop and Lightroom.

Camera2 can also provide more control over the image before you take it. The API now supports real, manual controls for focus, ISO, exposure time, and white balance.

At Google I/O, Google talked about some of the improvements it was able to make with the new API. On a Nexus 5, the fastest Android 4.4 could capture 8MP images (the sensor's max resolution) was at 3FPS. In Lollipop using the Camera2 API, it's 30FPS. And Android 4.4's 3FPS speed was for images with the same settings; Camera2 hits 30FPS with different settings per frame, so things like HDR can happen instantly instead of having to wait several seconds while the camera is reconfigured for multiple shots.

There's also no longer a difference between the photo and video modes. Before Lollipop, switching between the two modes involved a few taps on the UI side and an entire unloading of one pipeline and the loading of another internally. Now everything uses a single rendering pipeline through which a photo requests a single frame while a video requests 24 frames every second.

While this is all exciting groundwork, much of it remains hidden from users. Google Camera, the default camera app, doesn't support any of this new functionality. There's no way to manually control any of the camera settings or get a RAW image out of the camera with the default software.

For now you can play around with an "experimental" app, PkmX's "L Camera", which exposes some of the manual camera settings and will output in RAW. It crashes a lot, though. At the moment, it's too early to judge Google's progress in image capture.