The OTA updates are deltas unless you skip one, in which case it downloads the entire filesystem.
On Thu, Aug 27, 2015 at 1:17 PM Thomas A. Moulton <[email protected]> wrote: > 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 > > > > > > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
