latest
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. With the release of the L Developer Preview, new APIs were added to allow apps to request access to directories owned by other providers. Now that Android 5.0 Lollipop has been finalized, these APIs have been improved and even offer more capabilities than before, and they do it in a very user-friendly and secure way.
"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)
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. Google is apparently firming up its position on expandable storage even further, though, and in a way that limits flexibility and changes how we can use it.
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.
First, we heard that KitKat would bring some changes to the API, breaking many of the SMS apps we've come to rely on. On the day KitKat was released, we were given a more full explanation, shining some light on the technical details and exactly what types of apps would be affected. But did anybody really think this was the end of the story? It turns out that a hidden permission exists which can still grant non-default apps the right to modify the SMS database just like they used to - no rooting required.
You might remember a couple of weeks ago when Google gave developers a heads up about changes to KitKat that might cause problems for SMS apps. At the time, we knew that this only meant there would be a single app in charge of writing to the database, while all of the others would...well, that part wasn't really defined. Today, one in a series of developer videos gave us a little clarification on what it means to be a default app, and what it means for the rest of them.
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.
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.
In a post on the Android Developers Blog earlier today, Google has given us yet another indicator of upcoming changes to the Android platform. When KitKat launches, it will finally introduce a public API for the last remaining functions texting apps could not achieve without diving into private APIs. Developers are often advised to stay away from private APIs since they can change with each new version and may not be kept consistent across different OEMs.