Android Explorations

One of the new features Android M introduces is adoptable storage . This feature allows external storage devices such as SD cards or USB drives to be 'adopted' and used in the same manner as internal storage. What this means in practice is that both apps and their private data can be moved to the adopted storage device. In other words, this is another take on everyone's (except for widget authors...) favorite 2010 feature --  AppsOnSD . There are, of course, a few differences, the major one being that while AppsOnSD (just like app Android 4.1 app encryption ) creates per-app encrypted containers, adoptable storage encrypts the whole device. This short post will look at how adoptable storage encryption is implemented, and show how to decrypt and use adopted drives on any Linux machine. Adopting an USB drive In order to enable adoptable storage for devices connected via USB you need to execute the following command in the Android shell (presumably, this is not needed if your

Android M has been announced, and the first preview builds and documentation are now available . The most visible security-related change is, of course, runtime permissions , which impacts almost all applications, and may require significant app redesign in some cases. Permissions are getting more than enough coverage, so this post will look into a less obvious, but still quite significant security change in Android M -- the redesigned keystore (credential storage) and related APIs. (The Android keystore has been somewhat of a recurring topic on this blog, so you might want to check  older   posts  for some  perspective .) New keystore APIs Android M officially introduces several new keystore features into the framework API, but the underlying work to support them has been going on for quite a while in the AOSP master branch. The most visible new feature is support for generating and using symmetric keys that are protected by the system keystore. Storing symmetric keys has been pos

In a previous post  we looked at disk encryption enhancements introduced in Android 5.0. That article was written based on the Lollipop preview release, before the platform source code was available, and while the post got most of the details about hardware-backed key protection right (the official documentation has since been released), it appears that it was overly optimistic in expecting that high-end Lollipop devices will ship with hardware-accelerated disk encryption. Android 5.0 did come with disk encryption enabled by default (at least on Nexus devices), but FDE also brought some performance problems , and many Android enthusiasts rushed to disable it . While slower disk access generally doesn't affect perceived performance when using a particular app, longer load times can add up and result in slower switching between apps, as well as longer boot times. In order to improve performance without sacrificing device security Android 5.1 integrated support for hardware-accelerat

Android 5.0 (Lollipop) has been out for a while now, and most of its new features have been introduced, benchmarked, or complained about extensively. The new release also includes a number of of security enhancements , of which disk encryption has gotten probably the most media attention. Smart Lock (originally announced at Google I/O 2014), which allows bypassing the device lockscreen when certain environmental conditions are met, is probably the most user-visible new security feature. As such, it has also been discussed and blogged about extensively. However, because Smart Lock is a proprietary feature incorporated in Google Play Services, not many details about its implementation or security level are available. This post will look into the Android framework extensions that Smart Lock is build upon, show how to use them to create your own unlock method, and finally briefly discuss its Play Services implementation. Trust agents Smart Lock is build upon a new Lollipop feature cal

Some six months after the first early access chapters were announced , my book has now officially been  released . While the final ebook PDF has been available for a few weeks, you can now get all ebook formats (PDF, Mobi and ePub) directly from the publisher, No Starch Press . Print books are also ready and should start shipping tomorrow (Oct 24th). You can use the code UNDERTHEHOOD  when checking out for a 30% discount in the next few days. The book will also be available from  O'Reilly ,  Amazon  and other retailers in the coming weeks. This book would not have been possible without the efforts of Bill Pollock and Alison Law from No Starch, who edited, refined and produced my raw writings. +Kenny Root   reviewed all chapters and caught some embarrassing mistakes, all that are left are mine alone. Jorrit “ Chainfire ” Jongma reviewed my coverage of SuperSU and Jon “ jcase ” Sawyer contributed the foreword. Once again, a big thanks to everyone involved! About the book Th

In iOS 8, Apple has expanded the scope of data encryption and now mixes in the user's passcode with an unextractable hardware UID when deriving an encryption key, making it harder to extract data from iOS 8 devices. This has been somewhat of a hot topic lately, with opinions ranging from praise for Apple's new focus on serious security, to demands for "golden keys" to mobile devices to be magically conjured up. Naturally, the debate has spread to other OS's, and Google has announced that the upcoming Android L release will also have disk encryption enabled by default . Consequently, questions and speculation about the usefulness and strength of Android's disk encryption have sprung up on multiple forums, so this seems like a good time to take another look at its implementation. While Android L still hasn't been released yet, some of the improvements to disk encryption it introduces are apparent in the preview release, so this post will briefly introduce