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
WebViewimplementation is now overhauled, with Chromium at its core. While in theory your app should not change if your
android:targetSdkVersionis less than
19, you will want to double-check that as soon as possible. When you do start considering migrating to
19, please read the migration guide closely, as a lot has changed. Also, please note that you should be switching from
If you have not added the
READ_EXTERNAL_STORAGEpermission to your app yet (or
WRITE_EXTERNAL_STORAGE), and you are accepting
Urivalues from third-party apps, add the
READ_EXTERNAL_STORAGEpermission now. Otherwise, you may not be able to access the content at those
Urivalues, if they point to external storage.
The exception to the above rule is that
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
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
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
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
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.
ContentProvidercan 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
AlarmManagerwill need to bear in mind that
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
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
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,
the API differences report.
Need a speaker at your Android development meetup? Mark Murphy is available, in person in the Boston/Pittsburgh/DC triangle, or by remote anywhere in the world! Contact Mark for details!Tweet