From: Matthias Mohr <Matthias_at_mohrenclan.de>
Date: Wed, 11 Aug 2010 12:01:34 +0200

I'm also no Android specialist, so please forgive me if my thoughts don't make
sense on that platform.

> Right, but without some mechanism to load a newer build of rockbox (or
> a user build) it means than the android target can only run builds we
> release, which goes against the whole svn build system (imo).
Do I understand it correctly:
   on Android you don't have an user accessible .rockbox folder?
And therefore the user is unable to change configurations,
pictures, fonts, themes, wps files and so on e.g. with an editor?

Or does it get overwritten every time when he updates his package?

Both variations sound stupid to me - so I assume I misunderstood soemthing...


I suggest to define an update conecept which respects both "worlds",
the Android world and the rockbox world;
So provide Android release packages which gets updated with the usual Android
update mechanism.
And, as Jonathan suggested, let the rockbox software detect if a user provided
version exists and use that instead the package version.
It does not need to overwrite the package version, just execute it from
a different location...
And if space is a problem, provide two Android packages, one which contains
everything - but is not user changeable
and another one which only includes the "bootlader" and needs a user provided
version.

In the past I always used my own rockbox builds (for iRiver) with some
"private" features - I wouldn't want to loose that possibility for any
platform (and it shouldn't be necessary to sign an own build)...

I don't like the idea of having a nightly/svn Android package - IMHO it's too
much hassle to see every day a "package can be updated" on an Android device...

My two cents!

regards,
Matthias (aka Massa)
Received on 2010-08-11