Google encourages developers to define custom permissions to protect our publicly available activities and custom data providers. The first step is to define such permissions in your manifest so that your app as well as all other apps can display pretty text for the permissions. Apps that merely use your custom permissions will display the text you defined in your app for each permission. One issue I discovered is that you should never define the permission group as an empty string (android:permissionGroup=””) or else the permission definition becomes invalid and no other app will be able to use it.
Custom permissions should also define a custom Permission Group if they are not part of one of the Android built-in groups, otherwise they will be displayed as part of a permission called “Default” and all your custom permissions will be shown as a comma separated list underneath it. For example:
<?xml version="1.0" encoding="utf-8"?>
<uses-permission android:name="com.mydomain.provider.permission.ACCESS_DATA" />
<uses-permission android:name="com.mydomain.provider.permission.WRITE_DATA" />
Once you have defined all your permissions, other apps can simply use them with <uses-permission> and their apps will use your string definitions when displaying them in Settings as part of managing the device’s apps.
I have spent the last few days learning about how to use the new Android PreferenceFragment which requires PreferenceActivity to override a new v11 (Honeycomb) method called onBuildHeaders(). Unfortunately, the documentation is not very clear how one would create a single PreferenceActivity that could play well in all versions, utilizing the newest features if you have it and avoiding an app crash on older Android versions. I encountered several solutions to this issue by creating two different activities for the two different mechanisms requiring two entries in your AndroidManifest.xml file. Having two different PreferenceActivities means if you have library code that extends that class, you now have to duplicate it. Then, if your app descends your library class, now has to be duplicated yet again. The end result is … less than ideal. Continue reading →
Android drawable resources include the ability to provide and XML resource that specifies a different name for it’s bitmap resource. It is an especially handy mechanism for library code to refer to a specific drawable resource that your app provides under a different name.
For example a drawable xml named “app_icon.xml” could contain:
<!--?xml version="1.0" encoding="utf-8"?-->
If you used this kind of resource as your application’s icon resource inside your AndroidManifest.xml file, though, you have a problem. While technically, the app will function normally, the Android Market tries to check to make sure your app’s icon meets some guideline criteria and cannot handle an XML drawable. Android Market will refuse to upload your app and tell you “The icon for your application is not valid. Please use a 48×48 PNG.”
If you use XML drawables, please keep this limitation in mind and do not reference them inside your AndroidManifest.xml.
The Android 2.3 SDK in Eclipse enforces the optional Argument Index if you use multiple arguments inside a string resource.
Flagged as an error:
"Hello $s, %d days have gone by."
Google is taking issue with implicit argument ordering on the grounds that it is not Best Practice to leave it up to the translators to place the argument specifiers if they need to shift around the order due to language grammar. While I feel that taking away Continue reading →
I recently had a translator volunteer some time to translate one of my apps using MS Word on the strings.xml file. What I did not realize was that MS has a funny way of displaying XML files. MS Word will not display attributes by default, which means the name attribute is all but hidden from view. So instead of seeing the string:name attribute along with the string value that needs to be translated, all my volunteer could see was the string value. The name of the string could shed light on how that string was used in the app, so finding a way to present that information to my translator was a priority. Continue reading →