$ emulator -avd MYNAME -partition-size 300

Then:

$ adb remount
$ adb push ~/Desktop/rootfiles/su /system/bin/su
$ adb shell chmod 06755 /system/bin/su

The Android localization system, of course, uses the former approach. Each string is a resource with an id, each each language, essentially, has one or more XML files with the proper localized string mapped to each id.

For my apps, I initially used to have only the original English version, and a German translation, those being the only languages I speak, more or less anyway. Now, whenever I added a new English string, or changed an existing one, I immediately updated the German version as well – simply enough.

For A World Of Photo, I decided to ask the community for help with translations into more languages. Clearly, things were not so simple anymore.

See, with gettext, when the set of strings an app uses changes as part of a new version, you can simply “merge” the new string catalog into each of the translations. Strings that have been removed from the app are removed from the translations files, new strings are added, and strings that have been changed are flagged as “fuzzy”, at least to the extend that the merge tool detects it as a change, rather than a completely new string. That last part is possible because each translation file contains contains not only the translations, but also the original string that was translated. Remember, it’s the string that is the database key.

As a result, translators simply have to go through the list of new or fuzzy, update those, and they’re done.

Now, Android’s system has no equivalent tools. Frankly, I wonder how other people do this. I mean, you surely don’t want have your localization team go through the full list of strings every time you release a new version. Even if you decide you don’t need to ability to detect strings that have changed (you could simply have a policy of using a new id when such a change is necessary), you still need tools to merge changes in your main strings.xml file into each language’s XML resource with new/removed strings (do any such tools exist?).

I suppose you could also ask have your translators work off a diff, but that seems inconvenient. There’s this huge ecosystem around gettext with all kinds of desktop and web apps that could be utilized.

Google seems to use something internally, because Android’s own string resources are marked with msgid= attributes.

So, I decided the best way for me to deal with this would be to simply convert Android’s XML resources to gettext, do the translations, then import the result back to Android. I found out that the OpenIntents project was doing the same, essentially using a generic xml2po tool found somewhere in the depths of gnome-doc-utils. I kinda got it to work, but ran into a lot of little issues; in the end it felt just too hacky.
The final thing that convinced me that writing a special purpose tool might be worth my while was the fact that Android’s XML resource format has a bunch of different escaping rules and peculiarities (which I plan to write a separate post on), with which translators shouldn’t really have to deal with.

So, have a look at android2po. You can install via PyPi:

easy_install android2po

There’s also a README file which explains the basic usage; which is really just a2po init, a2po export and a2po import calls, though at this point there’s also various configuration options that should make it really quite flexible.

The biggest thing it doesn’t support yet are the <plurals> tags, mainly because I didn’t need them myself yet. Apart from that, I do believe it should work just fine for most projects.

Unfortunately, both TextView and the Linkify utility it uses basically hardcode URL click handling to Intents, by way of the URLSpans they create. What if we want the link to affect something within your own Activity, say, display a dialog, or enable a filter?

For example, in Autostarts, if the user’s filters cause the application list to be empty, I wanted to display an explanatory message, and provide a quick and easy way for the user to rectify the situation, i.e. lead him towards the filter selection dialog. Making the whole text clickable is hard to get right visually, and I didn’t like the idea of a button too much. A link within the text seemed perfect.

Now, we could just use a custom URL scheme of course, and register our Activity to handle Intents for that scheme, but that seemed much too heavy, if not hacky. Why shouldn’t we be able to just hook up an onClick handler?

As mentioned, URLSpan doesn’t allow us to change the way it handles clicks (it always sends off an Intent), but we can create a subclass:

static class InternalURLSpan extends ClickableSpan {
	OnClickListener mListener;

	public InternalURLSpan(OnClickListener listener) {
		mListener = listener;
	}

	@Override
	public void onClick(View widget) {
		mListener.onClick(widget);
	}
}

That looks pretty decent. Actually using that class it is tougher. There is no way to tell TextView or Linkify to use our custom span. In fact, Linkify actually has a method (applyLink) that would be nearly perfect to override, but declares it final.

So, we end up having to generate the spans manually; note nice, but hey, it works.

SpannableString f = new SpannableString("....")
f.setSpan(new InternalURLSpan(new OnClickListener() {
        public void onClick(View v) {
            showDialog(DIALOG_VIEW_OPTIONS);
        }
    }), x, y, Spanned.SPAN_EXCLUSIVE_EXCLUSIVE);

We probably also want the user to jump to your link my moving the focus (e.g. using the trackball), which we can do by setting the proper movement method:

MovementMethod m = emptyText.getMovementMethod();
if ((m == null) || !(m instanceof LinkMovementMethod)) {
    if (textView.getLinksClickable()) {
        textView.setMovementMethod(LinkMovementMethod.getInstance());
    }
}

[via]

Use a thread, not just a service

In the blog post introducing the AppWidget framework, you are encouraged to use a service to perform your widget updates if you are doing anything that might take a little longer, in order to avoid Application Not Responding (ANR) timeouts. However, this will usually not be enough. Since your service callbacks also run in your application’s main thread, you’ll still be in danger of triggering ANR as soon as your process is asked to do other things while still being busy with your first widget update. For example, your widget’s broadcast receiver might be triggered again for another instance of your widget, or the user might start interacting.

The solution is to have your service start a separate thread. For an example, see Jeffrey Sharkey’s android-sky Widget.

Stop your service when you’re done

When your done with updating (if your using a thread, it’ll be when your thread has finished), make sure you stop your service. Nobody seems to be doing this, including the example code in the official blog post, nor sample projects by Android team members. As a result, so many widgets have their process run in the background all the time, not allowing Android to kill it to reclaim memory. Considering that RAM isn’t exactly a plentiful resource on devices like the G1, I would have thought this were especially important. Unless your updating multiple times an hour, I would strongly suggest that stopping your service and letting Android free up your process when necessary is the right thing to do.

Try to work around the bugs in Android 1.5 and the Launcher’s Widget implementation

It turns out there are quite a few of them, and they all seem to revolve around issues with deleting a widget. In particular:

• AppWidgetProvider fails to handle delete intents correctly. As a result, if you are subclassing it, your onDelete() method will not be called. The solution is to override onReceive() and handling delete intents yourself. Here’s a code snippet.
• In any case, if a user deletes an instance of your widget, the 1.5 default home screen will still keep sending update requests for the already deleted widget’s id, until the user adds a new instance of your widget (apparently, some internal bundle of widget ids is not reset on delete). This seems like this could result in a considerable waste of resources, or even impact your functionality, with you sending out widget updates that nobody is going to see. Note: I’m not sure if those obsolete widget ids are cleared out on reboot (probably). You might also not have this problem if you’re using custom scheduling instead of the default update facility.
  The best one can do here appears to be keeping an internal list of deleted widgets (widgets for which you – hopefully – received a delete intent), and then just skipping those updates.
• Finally, there seems to be another issue with phantom widgets when a configure activity is used and the user cancels it. In this case also, you’ll continue to receive updates for the widget (which won’t be shown anywhere), except it seems even worse, because apparently this time around, widget will really exist internally, rather than just some internal state not being update correctly (so even a reboot won’t help here).
  The work around seems similar: keep information around that indicates whether a widget as been configured successfully, and don’t bother updating widgets that haven’t.

2009-07-18: It appears there is another widget bug.

Eclipse is loading framework information and the Layout library from the SDK folder.  file.xml will refresh automatically once the process is finished.

Of course, the process never finished. Because I never had any use for the old version, at first I didn’t even know something was wrong.

There seem to be a handful of people out there with the same problem, although none of the suggested solutions worked for me. Until I found this Spanish site. It turns I should have uninstalled the old Eclipse plugin before installing the 1.5 SDK one. In my plugin directory (~/.eclipse/plugins), there were still .jar files from the old version around (named 0.8, apparently). Simple removing those files and restarting Eclipse did the trick for me.

Package x.y.z has mismatched uid: 10089 on disk, 10079 in settings

Here’s the Python script I used to apply the file system permissions that Android expected. It iterates over the packages defined in your devices /data/system/packages.xml. Use at your own risk.

"""Parse Android's /data/system/packages.xml file and spits out
shell code to fix UIDs.

This helps you fix "Package x.y.z has mismatched uid: 10089 on disk, 10079
in settings" errors.
"""

from xml.dom import minidom

xmldoc = minidom.parse('packages.xml')

packages = xmldoc.getElementsByTagName('package')
ignored = []
for package in packages:
    try:
        userId = package.attributes['userId'].value
        is_shared = False
    except KeyError:
        userId = package.attributes['sharedUserId'].value
        is_shared = True

    # do not touch permissions of shared apks (they userid always seems to be 1000)
    if not is_shared:
        print "busybox chown %s:%s %s" % (userId, userId, package.attributes['codePath'].value) 

    for subdir in ('', 'databases', 'shared_prefs'):  # note we don't touch lib/
        print "busybox chown %s %s:%s /data/data/%s/%s" % (
            '-R' if subdir else '', userId, userId, package.attributes['name'].value, subdir)

adb logcat was usuable at that point, and kept looping messages like:

D/AndroidRuntime(   66): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<
D/AndroidRuntime(   66): CheckJNI is OFF
D/dalvikvm(   66): DexOpt: incorrect opt magic number (0xff ff ff ff)
D/dalvikvm(   66): Stale deps in cache file; removing and retrying
W/dalvikvm(   66): partial write in inflate (8152 vs 32768)
E/dalvikvm(   66): Unable to extract+optimize DEX from ‘/system/framework/framework.jar’
D/dalvikvm(   66): Failed on ‘/system/framework/framework.jar’ (boot=1)
D/dalvikvm(   66): VM cleaning up
D/dalvikvm(   66): LinearAlloc 0×0 used 4100 of 4194304 (0%)
W/dalvikvm(   66): JNI_CreateJavaVM failed
E/AndroidRuntime(   66): JNI_CreateJavaVM failed

Turns out that the 8MB free space I had on my data partition were not enough for the update. Removing a couple larger apps through the shell let the boot process continue (though in the end, I used a backup to start a new, “clean” update).  All in all, the update needed an additional 22 MB on my phone. I’m not sure if this is JF specific and the actual 1.5 image is smaller, but, if you run into trouble, this might be the reason.

For example, create a resource file in ./res/values/dimens.xml and add this item:

<dimen name=table_padding>10dp</dimen>

Then, from within your activity you would do:

int tablePadding = getResources().getDimensionPixelSize(R.dimen.table_padding);

I wonder whether the conversion code used by getDimension/getDimensionPixelSize is exposed somewhere.

Edit April 2010: There’s actually a snippet in this document about screen sizes, which is essentially this function:

private int dipToPixels(float dipValue) {
     return (int) (dipValue * getResources().getDisplayMetrics().density + 0.5f);
}

As far as I can tell, the +0.5 part is intended to ensure that the result is at least 1 pixel always.