ubuntu-phone team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

On Thu, Aug 27, 2015 at 7:14 AM, John McAleely <john.mcaleely@xxxxxxxxxxxxx>
wrote:

> As we begin to prepare for new features associated with converged devices,
> it seems likely that some image configurations will be *much* larger than
> our current phone images on system-image.ubuntu.com
>
> As an example, I've been anecdotally informed that if an OEM wanted to
> bundle libreoffice (a likely scenario) that may add around 500M to the
> image size.
>
> Currently, we download images three ways:
>
>  - Via system updates to the phone, where the download is pulled to the
> cache partition
>  - Via a host desktop and then via ubuntu-device-flash to the phone.
> Again, this writes the (compressed) images to the cache partition as a
> staging step
>  - Via various factory flashing tools, which simply write whole partitions
> as-is (similar to how dd might work)
>
> Typically, the cache partition on android devices seems to be in the range
> 500-700M, and it it certain that some desirable converged device
> configurations will have images that (in compressed form) are much larger
> than this. The first two flashing methods will clearly break.
>
> A simple solution to this problem is to increase the size of the cache
> partition on devices where large applications might be installed. Fine for
> those devices where we control the partition table, but impossible on those
> devices where we co-exist with android and don't change that table.
>
> Those devices where the partition table can't be modified includes Mako,
> Flo, etc.
>
> For those devices, we clearly need to make changes to how images can be
> downloaded, if we wish to support these devices for convergence images.
>
> One choice would simply be to reserve a sufficiently large amount of space
> in the userdata area of the android partition table, and ask our image
> flashing tools to use that. We would then ignore the cache partition
> entirely for the flashing process on these phones.
>
> Is it just the download/updater (including recovery) that is impacted, or
> are other actors involved in preparing system updates?
>

This could be solved with having an entry in channels.ini (if it is not
there already) with the preferred storage location for updates and have all
clients respect that. I just say channels.ini because it is common to all,
there may be a better location.

The recovery script may not need to know about this, but the client
generating the update script would and it would generate an update script
with the right commands. I haven't checked if this would be supported out
of the box, I'm just saying that when in recovery we shouldn't need any
special flag if the update commands are done right.