To avoid the Out of memory error when trying to copy the su-executable to /system/bin, you need to start the emulator manually with a large –partion-size argument:
$ emulator -avd MYNAME -partition-size 300
Then:
$ adb remount $ adb push ~/Desktop/rootfiles/su /system/bin/su $ adb shell chmod 06755 /system/bin/su
I’ve always liked gettext a lot. Rather than asking you to maintain a database of strings, assigning an id to each, it simply uses the original strings itself as the string id. To me, it’s a classical example of choosing practicality over purity.
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.
Android’s TextView widget can contain clickable URLs. It can easily make web addresses open in the browser, or connect phone numbers with the dialer. All that is amazing compared to the last GUI framework I used, Delphi’s once great VCL).
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());
}
}
if ("1".equals(SystemProperties.get("ro.kernel.qemu")) {
// Emulator
}
[via]
2014-09-09 – This has been updated, see below.
Having recently written my first Widget for Android, here are some of the things I learned in the process.
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 going to trigger ANRs if you do work there. Services really just declarative components, metadata that tell the system “I would appreciate if you wouldn’t kill me”.
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:
2009-07-18: It appears there is another widget bug.
In my experience, this has all been fixed, with one small note.
Here is what I know about phantom widgets.
AppWidgetProvider.onUpdate is called before the widget is configured
The documentation to this day claims that this is not so (“the system will not send the ACTION_APPWIDGET_UPDATE broadcast when a configuration Activity is launched“), but at least on my Sony Xperia with Android 4.4, this is not the case. Admittedly, Sony is using a custom home screen. At least you cannot rely on this, then.
The solution is simple though: Simply ignore that first update, that the docs claim shouldn’t be sent. Note whether a particular app widget id has been configured, then only process updates for widgets that have been configured.
When the user cancels the configuration activity, AppWidgetProvider.onDelete is called.
If you chose not to ignore that first update, that was sent before your widget’s configuration activity completed, you will get the onDelete callback once the configuration activity is canceled. Just be sure to set the RESULT_CANCELED return intent. Do this in onCreate, and then simply override the result value it when the user completes the configuration. This is much more simpler and more reliable than trying to cancel in onBackPress or onStop or onPause.
With the RESULT_CANCELLED value properly returned, I reliably receive onDelete callbacks, whether I exit the configuration activity via BACK or HOME.
If you use your own scheduler, you will still receive those events!
This was throwing me off first, but since I’m scheduling my own widget updates using AlarmManager, any such alarm already scheduled will still be delivered, even after the user has deleted your widget. To Android, your custom alarms have nothing to do with the widget, after all.
So you’ll either have to cancel those alarms, or, which is what I do, if only for historical reasons due to the bugs that existed five years ago, I mark the widget as deleted when it is removed, and subsequently ignore everything coming in for deleted widget ids.
Android’s layout editor for Eclipse is much improved in the 1.5 SDK vs. the old 1.0/1.1 versions. Unfortunately, I didn’t realize that until yesterday, because the new controls didn’t show up for me. Instead, Eclipse just said:
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.
A while ago, I set up Apps2SD on my ADP, and while I am not sure what, I must have done something wrong, because afterwards, Android refused to boot properly, claiming that the file system permissions of pretty much all installed packages didn’t match up:
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)
While upgrading my G1 to the new 1.5 JF image, the system wouldn’t come back up after applying the update.zip file (yes, it’s normal that the first reboot takes a while, but this was too long).
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 0x0 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.
When designing a layout in XML, Android supports a number of different metrics. From your Java code though, methods like setPadding or setTextSize only take absolute pixel values. It took me a while to find a solution, but apparently the (slightly too cumbersome, I feel) way to to this is through defining a Dimension Resource.
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.
blog.elsdoerfer.name 