Question

An Android application that I am interested in (OpenSudoku) has become unmaintained by the original author, who last updated the application just under a year ago, in addition they have rejects offers of help from others to contribute directly to the hosted SVN repository.

I am interested enough in the project to seriously consider forking it (I am already familar with many arguments for and against forking in general), but I do have a couple of questions related to best practice with forking Android applications, specifically:

1. I understand that I will have to change the package name/namespace, is there an easy method I can use to do this (without breaking the Eclipse project files and associated references)?
2. Is there a way to help users that may want to migrate to the new application, recover settings/data from the original application? (My understanding is that the permissions model that Android enforces would make this impossible)?
3. Are there any other issues that I should be aware of that comes with forking an Android application that I would need to plan for?

Answer 1

1. AndroidManifest.xml, various build system files, layouts that use your own views, each Java source file, and the directory tree. That’s what you have to change. I use vim -p glob glob glob for changes like this, and mv, which is easy enough.

2. Not unless the old application cooperates, which it likely doesn’t. Perhaps your fork could detect an OpenSudoku install and prompt the user to install, off-market, an ‘update’ for it that just repackages its preferences for your consumption. I don’t know if that works, updating a Market app with a non-market APK. Although, you said “settings/data”. If ‘data’ includes e.g. sets of puzzles on the sdcard, yes, you can load that kind of data without any trouble — FAT32 offers no security.