On 11 August 2010 20:01, Thomas Martitz
<thomas.martitz_at_student.htw-berlin.de> wrote:
>  I'm starting to like that idea. I'm not so worried about the download size,
> but about the size it needs on the internal flash memory. The available
> space there is quite tight for many people and they will be unhappy/angry if
> we use like 20MB because we support 10 screen resolutions in a single .apk.
> Remember, the .apk itself is also stored there not only the extracted one.

Does that mean you are in favour of the download on first use version?

>
> It could maybe only check for an updated rockbox.zip if it was just
> installed/updated from the market, do not bypass the update-via-marked thing
> too much.

Right now the patch checks for rockbox.zip in the Activity's onCreate
(before the service is started) which I tihnk makes the most sense.
Until we figure out how to fully restart the service I don't see it as
a bad thing that the user would need to forcibly kill the service and
activity to reload their new rockbox.zip. I dont think the activity
should ever download except for new releases (which is when we would
push a new version to market).

>
> I fear a one-apk-fits-all-screens apk isn't going to work really well
> (unless we can manage to make Rockbox not rely on a fixed screen size that
> is).
>
Indeed, but that would only fix half of the problem. I still think
being able to load a custom/current build is higher priority than
making the binary scale graphics properly.
Received on 2010-08-11