[Scummvm-devel] Status of ScummVM Android port

Andre Heider a.heider at gmail.com
Wed Apr 6 12:22:29 CEST 2011

On Wed, Apr 6, 2011 at 11:31 AM, Max Horn <max at quendi.de> wrote:
>>  The only non-ideal part of this is 1b, and I can't
>> see a way out of that without breaking upgrades, losing savegames and
>> other badness.
>> (We can switch almost all the java code over to use another namespace,
>> but we have to leave the apk package name and I think the main
>> activity class as org.inodes.gus.scummvm)

We already have the savegame issue with the nightlies. To summarize:
You can't update a package when the signing key differs. In that case,
only uninstall+reinstall is possible. Every package has its own data
and cache path, the former contains the savegames (if the user didn't
specify another in the options dlg). On uninstall, both paths are
wiped. Per Android design, every package gets its own uid, and only
that uid has access rights to the private paths. If the application
doesn't have a feature to copy/move files out of there, the user
doesn't have any way to get to those files (uid 0 can do that, but
rooting a device is something we should't tell our users to do for
this purpose).

What I had in mind:
Move the default savegame path, so it points to SD. Add migration
code, that detects savegames files on the old path and move them to
the new one.
When shipping packages with that feature using gus' key, users won't
lose anything and can uninstall safely afterwards.

For a later version, we can then change keys and package properties as
we see fit.

About the current packages:
There is a main package and one for each engine. When the main app is
launched, it looks for installed plugin packages, and copies all .so
engine plugins over to its own cache path. This is slow and wastes
There's a "shared user id" package property. When using that for all
our packages, the main app should be able to access the plugin .so's
directly (didn't test yet if that works for dlopen() for native code,
but in theory it does).
But it's not possible to introduce that change now, because Android's
package manager doesn't allow an upgrade then - same issue as with
changing keys. The shared uid has to be set on the initial public

That's something I'd like to do, and it would be the perfect timing to
rename to org.scummvm.scummvm. But it means that users have to
uninstall and reinstall once.

Angus: Did you look into or try to use the shared user id?


More information about the Scummvm-devel mailing list