<img src="http://cdni.wired.co.uk/138x138/a_c/ars.png" alt="Ars Technica" style="float: left;"/>When Google announced the L release of Android at its keynote recently, much of the presentation focused on the operating system's new design. We did the same thing in our
initial first-blush post about the operating system. That's fine -- it's the thing that most people will look at and interact with, so it will affect the most people.
Android releases don't just introduce visuals, though. They also add new, under-the-hood features that improve the operating system in not-always-apparent ways. Google touched upon some of these in the keynote, but we wanted to spend a little more time on a few of the changes that we think are most important.
ART
This is a big one, and since Google spent some time talking about it at the keynote there's a good chance you know about it already.
Google is replacing the old Dalvik application runtime with the Android Runtime (ART), which was introduced as an optional developer feature in version 4.4. Google has further improved ART in the L release, but in concept it remains the same as before.
Dalvik uses a just-in-time (JIT) complier, which means that bytecode is compiled into native code on-the-fly each time applications are launched -- bytecode is small and portable, so this approach made sense on early space-constrained Android handsets. ART, on the other hand, largely uses an ahead-of-time (AOT) compiler, which compiles the bytecode to native code once when applications are installed and then doesn't have to recompile them again. If you've already used ART in Android 4.4, you may have noticed that applications take longer to install from the Google Play store when you first download them -- that's because the code is being compiled up-front rather than at launch.
ART makes a couple of tradeoffs (the speed of installation and the amount of storage space that native code takes up compared to bytecode are two of the more noticeable ones), but in general it improves performance and makes it more consistent. ART can take the time to better optimise applications the one time they're compiled -- doing similar optimisation using Dalvik would introduce extra latency every time you open the application. CPU time saved from compiling ahead of time should marginally improve battery life, and Google says that ART will help reduce memory usage for applications as well.
As people who have used ART and KitKat will already know, the vast majority of Android apps should work with the new runtime with no additional effort needed from developers. AnandTech has a more thorough look at ART here, including more about its improved garbage collection algorithms, its support for both 32-bit and 64-bit ARM, x86, and MIPS CPU architectures, and more of Google's official ART benchmarks.
Project Volta, Battery Saver, and Scheduling Jobs
The L release is fighting the battle to extend your battery life on several fronts, a bundle of improvements collectively called "Project Volta." We already ran a Nexus 5 with the Android L preview on it through our battery test and came away impressed with the results, though this early in development results may vary widely (a 2013 Nexus 7 run through the exact same test actually lost about half an hour of battery life, so take that as you will).
More drastic and consistent battery life gains will depend on users and developers changing their behaviour. For users, there's an improved battery life tracker that tells you more about what's draining your battery and informs you the time remaining in your current charge (and, while charging, the time until your battery is full). Developers get new "Scheduling Jobs" APIs that let their apps put off background tasks until you're on Wi-Fi instead of cellular or plugged in instead of running on battery power. They can also take advantage of new developer tools for examining battery life, like the dumpsys batterystats command.
Another addition is the new Battery Saver feature, accessible in the Battery section in the Settings app. It's similar to battery saver features implemented by OEMs in their own handsets -- toggling it dims the display slightly, removes many OS animation effects, and slows the CPU down (some quick benchmarks show a performance penalty of roughly 20 or 25 percent in battery saver mode). If our Nexus 7 is any indication, you'll definitely be able to tell when you're in Battery Saver mode. Even swiping between pages on the home screen is noticeably choppy in the preview, though in a pinch a choppy tablet with some battery left is going to be more useful than a silky-smooth phone that's out of juice.
Battery Saver can be enabled manually, and it kicks in automatically when your battery drops down to 15 percent. You can change that value or disable the feature entirely if you want.
Camera API/DNG support
Android L's new camera API brings the rumoured RAW support in the form of a new DngCreator class, highlighted here by Android Police. It will allow applications to save images in the "Digital Negative" (DNG) format. Like RAW, DNG images haven't been processed by the phone, preserving more of the information the camera sensor picked up when the picture was taken. This makes it easier to doctor and manipulate the image after the fact if it turns out that your picture is too dark or the white balance was off. It's a great feature given how iffy most Android phones are at image processing.
Also new is a camera API that opens up most of your camera's advanced settings to third-party applications. While Google's official Android camera app focuses on simplicity, other more advanced apps will be able to take full manual control of the hardware so that advanced photographers can get better results.
Improved audio support
Android L brings a whole bunch of good stuff for Android audiophiles, best summarised in this Geeknizer report. First up, it will get better at real-time audio operations requires for auto-tuning and karaoke apps to work well. The developers of one prominent karaoke app told GigaOm that older versions of Android could introduce as much as 200ms of audio latency, which has reportedly been reduced to about 20ms in the L release.
The L release adds official support for the 96kHz sample rate and 24-bit depth, up from 44/48Khz and 16-bit depth, and it improves audio resampling for when the file you're listening to uses a different sample rate than the digital-to-analog (DAC) converter in your device. USB audio support will allow you to use external DACs with your phones and tablets, too.
Bluetooth 4.1
Android was relatively slow to embrace the Bluetooth 4.0 specification, officially integrating it into the operating system nearly three years after it was finalised. The turnaround time for
Bluetooth 4.1 support will be much quicker -- the spec was finalised in December of 2013, and it will be supported by Android L when it's out in the fall.
The update is smaller than Bluetooth 4.0, but it adds a few nice-to-haves to a standard that will only be used more as every device you own starts trying to talk to your phone.
Version 4.1 addresses interference with LTE radios that use similar frequencies, will allow smart devices to talk to each other in addition to your phone, and makes it easier for devices to maintain a connection (and to find each other if the connection has been interrupted). In addition, it improves "bulk data transfer" operations -- one example the Bluetooth SIG uses is a fitness band that has been worn on a jog that connects to and transfers sensor information to a phone when you get back home.
The nice thing about Bluetooth 4.1 is that it shouldn't require new hardware -- anything that works with Bluetooth 4.0 should be able to upgrade. It also shouldn't require recertification of existing devices by the FCC and other regulatory bodies.
OpenGL ES 3.1 and the "Android Extension Pack"
Like the Bluetooth upgrade, this one is rather small but still important for future-proofing. OpenGL ES 3.1 builds on OpenGL ES 3.0, which was first supported by Android 4.3 on capable hardware with compatible drivers. The Khronos Group, responsible for managing the standard, says that most OpenGL ES 3.0-capable hardware should be able to support version 3.1 with a driver update.
The most important thing ES 3.1 introduces is support for compute shaders. This feature enables GPU hardware to be used for non-graphical things like physics calculations, and it allows for certain graphical tasks to be completed more efficiently. This video here shows computer shaders being used to generate a large group of particles, for example. The update also brings the mobile OpenGL ES standard a little closer to the standard OpenGL 4.4 standard.
Google has added an "Android Extension Pack" to the standard OpenGL spec to add a few more capabilities, including "guaranteed fragment shader support for shader storage buffers, images, and atomics," tessellation and geometry shaders, and a few other bits and pieces.
It doesn't go as far as Apple's new Metal API, which follows AMD's Mantle and precedes Microsoft's DirectX 12 in providing lower-level access to the GPU, but the features are there for Android game developers who care to use them.
This article originally appeared on Ars Technica
This article was originally published by WIRED UK
