Quick Musings on Android 4.4

Based on a quick review of the documented changes for Android 4.4, here are some preliminary thoughts regarding areas of potential incompatibility with your app, beyond the SMS changes that I blogged about previously, and of particular relevance to readers of my book:

• If you are using WebView, start testing your app on Android 4.4 immediately. The WebView implementation is now overhauled, with Chromium at its core. While in theory your app should not change if your android:targetSdkVersion is less than 19, you will want to double-check that as soon as possible. When you do start considering migrating to android:targetSdkVersion of 19, please read the migration guide closely, as a lot has changed. Also, please note that you should be switching from loadUrl("javascript:...") to evaluateJavascript(), as “ Apps targetting KITKAT or later that load a JS URL will have the result of that URL replace the content of the current page”.

• If you have not added the READ_EXTERNAL_STORAGE permission to your app yet (or WRITE_EXTERNAL_STORAGE), and you are accepting Uri values from third-party apps, add the READ_EXTERNAL_STORAGE permission now. Otherwise, you may not be able to access the content at those Uri values, if they point to external storage.

• The exception to the above rule is that getExternalFilesDir(), getExternalCacheDir(), and their new plural equivalents (e.g., getExternalFilesDirs()), do not require READ_EXTERNAL_STORAGE. Basically, if you stick to your own application specific location(s), you do not need the permission, but you do if you write anywhere else on external storage.

• The first crack in the “one external storage only” policy has occurred, as now there are getExternalFilesDirs() and getExternalCacheDirs() methods on Context. These can return multiple values, representing locations on multiple forms of external storage (e.g., on-board flash partition and a removable card). Of course, it requires a manufacturer to actually support this. And, since no Nexus device has removable card support, the only near-term way we might see how this behaves will be via USB OTG accessing a thumb drive or something, and that’s no sure thing. And, there is no plural equivalent for the classic methods on Environment (e.g., getExternalStorageDirectory()), so while this is a “tip o’ the cap” in the direction of multiple forms of external storage, it is unlikely to completely solve developers’ problems in this area.

• The release notes indicate that Android 4.4 will “now more aggressively protect system memory from apps consuming large amounts of RAM”. The only concrete explanation of what that might mean probably is misstated. The release notes say “When multiple services start at once — such as when network connectivity changes — Android now launches the services serially, in small groups, to avoid peak memory demands”. However, services cannot respond directly to things like “network connectivity changes” and not be running already — such changes are handled via listeners (requiring an already-running service) or a broadcast Intent (which does not necessarily imply anything about a service). Hence, at least at the moment, I am interpreting “services” as “processes” in those release notes, as that would make a bit more sense. It does mean, though, that apps relying upon rapid response to system broadcasts may encounter unexpected delays.

• Once you target API Level 19 or higher, you will need to override isValidFragment() in your PreferenceActivity, to validate that the supplied fragment class name is indeed something that should be displayed. Off the cuff, this feels like some hack to deal with a security flaw.

• Note that there is a new density, known as DENSITY_400 in DisplayMetrics. You should only really need to worry about this if you are working with density buckets directly in Java code or are seriously anal about pixel perfection with your drawable resources.

• A ContentProvider can now have an <intent-filter>, in support of the new document provider framework. It is unclear what this will mean for other providers, if anything.

• Those of you using AlarmManager will need to bear in mind that set() and setRepeating() will start becoming inexact once you target API Level 19. Sync adapters will similarly “flex” their scheduling. Both of these are in the interests of saving power.

• App Ops seems to be making a comeback, but since I do not see KitKat source code available, I am reserving further judgement until I get my hands on some Android 4.4 hardware.

• Only having an ARM emulator makes $BABY_DEITY cry.

There are likely plenty of other areas of compatibility concern, in areas beyond the scope of my book (e.g., media changes). You should review the KITKAT version details to learn more about changes that will occur when you change your android:targetSdkVersion to 19 or higher, in addition to the release notes, the other release notes, and the API differences report.