Over the last few years, few topics have been more hotly contested by Android users and developers than how SD cards are handled by the OS. Back in February, I discussed some of Google's changes during the transition from Android 2.3 to 4.0, and then how more recent policy changes ultimately led to 3rd-party applications losing most of their access to removable storage. By the time I/O came around, Google acknowledged that KitKat's newly added Storage Access Framework still didn't offer enough range for apps to get their work done.
"Because the history of computing has taught us is that data will not be contained. Data breaks free. It expands to new media, crashes through barriers; painfully, maybe even dangerously. But, uh, there it is… Data finds a way." - Jeff Goldblum as Jeff Goldblum (Jurassic Gift Shop)
When we last left our favorite removable storage device, OEMs had begun adopting Google’s policy for restricting write access to SD cards.
Intel's progress into the Android ecosystem hasn't exactly been earth-shattering. The number of high-end and mid-range smartphones equipped with an ATOM CPU still number in the single digits, making the x86 architecture a fairly low priority for app developers. In addition, Intel's emulator images have always lacked support for the Google APIs, leaving developers without the ability to test common staples like Google Maps or push messaging. Fortunately, that issue was recently rectified with KitKat as Google and Intel have finally shipped an x86 system image with Google API support.
In recent years, Google hasn’t exactly been known as particularly hospitable toward SD cards with regard to its Android operating system. This theme is most often associated with the Nexus line of devices - the Nexus One was the only such handset to ever offer expandable storage. But despite arguments from Dan Morrill and Matias Duarte suggesting this stance is about keeping the Android interface simple and file picker-free, people still want more space.
A brand new OTA began rolling out to the 2013 Nexus 7 LTE just two days ago, and today those changes finally appeared in AOSP. As is the tradition, Al Sutton built a list of changes and posted them to his site. Every bug fix and tweak from KOT49H (4.4.2_r1) to KVT49L (4.4.2_r2) is included. There isn't a lot to look at, but if you're interested in what's new, you can find the developer changelog here.
Just hours ago the source code for Android 4.4.2 went live on AOSP, and now we already have our changelog from Al Sutton. With only four meaningful changes, this is probably the smallest changelog we've ever seen. That's not to say it isn't significant, as it further hides away App Ops and also shores up two fairly serious vulnerabilities.
Earlier today, the Nexus and KitKat crowds almost had collective heart attacks when they saw that kitkat.com/android was now password-protected and likely hiding something behind the locked gates. Possibly even all the complete KitKat details we've been dying to see (or whatever is left of them anyway). Could it be? Did the site go down for the big update, and the launch is imminent? Not so fast.
While the page does indeed pop up a login dialog, the revelation doesn't really mean anything just yet.
Feedly has replaced the much-loved Google Reader for quite a few of you, so we tend to pay attention when a new version hits the Play Store. Today the Android app has been updated to version 17 with a laundry list of improvements and tweaks. There's nothing game-changing in there (though arguably the "300% faster start time" is a big deal), but it does include "support for Android Kitkat." No, the developers are not elaborating on that.