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.
