ubuntu-phone team mailing list archive

["Thomas A. Moulton" <tom@xxxxxxxxxx>]

>From watching the various updates my Tablet (flo) has received, aren't
the OTA updates deltas? If so, then would it be expected to have >500MB
of changes between updates often? In the most recent update I think I
saw about 148MB downloaded.

Could this be a temporary problem, because aren't  we going to migrate
to a Snappy based system at some point? Then with the System-ab
partitions some of the rules may change, such as writing updates to
System-B while we're running in A, not requiring a single download to
have everything.

TOTAL Speculation on my part...

I am also not sure of the sequence of events of Snappy and Convegence.

Tom

On 08/27/2015 06:14 AM, John McAleely 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
> <http://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?
> 
> J
> 
> 
>