search

GloDroidCommunity / raspberry-pi

Android 14 for the Raspberry PI 4 series based on the GloDroid project
Apache License 2.0
28 stars 5 forks source link

Increase super size to ensure device updateability #8

Closed mikegapinski closed 1 year ago

mikegapinski commented 1 year ago

Current super size does not take consider OTA updates. When the update is installing the snapshots for the new slot are stored on /data and the user needs to have a certain amount of free space on the partition to install the update. This is not the recommended way of handling OTA according to https://source.android.com/docs/core/ota/dynamic_partitions/how_to_size_super?hl=en

I've taken 2.5GB as a base for my calculations, super size with slim gapps is 2455498752 for me. 7.5GB enables OTA without having to rely on /data for snapshots with room to grow:

FinalDessertSize = FactorySize + (FactorySize ExpectedGrowth) Super = Max(FinalDessertUpdate, FinalDessertSize 2 - AllowedUserdataUse)

ExpectedGrowth=0.5; AllowedUserdataUse=0

7.5GB is conservative, GS101/201 use 8.5GB now but I doubt anyone uses full gapps on GloDroid.

I also compress the sdcard img to make it more manageable:

-rw-rw-r-- 1 mgapinski mgapinski 10737418240 kwi 8 18:58 sdcard.img -rw-rw-r-- 1 mgapinski mgapinski 1167841252 kwi 8 19:01 sdcard.img.tar.gz

I know it's a huge bump in image size but let's face it, people should not use small and slow sdcards to begin with

rsglobal commented 1 year ago

My concern is that there needs to be a generic solution for this issue, and SUPER partition size needs to be determined separately for every device / build.

E.g., some distros may want OTA installation as early as possible. Therefore reserving the super partition for both A and B slots seems reasonable.

But some distros may not force users to update immediately. Therefore updater app can warn users to free some space to perform the update. In such a case, 3.2GB is more than enough.

Some distros may have 32-bit only or 64-bit only components. For such scenarios, 2.5GB may be a perfect size.

Some distros may use compressed file systems, and so on.

Would be nice to have a single definition, e.g.: 'GD_SUPER_SIZE_MB := `, and propagate it into both base/board.mk and the bootscript.

getsdimg.sh may read super.img size and adjust the total sdcard.img size based on the value.

mikegapinski commented 1 year ago

My concern is that there needs to be a generic solution for this issue, and SUPER partition size needs to be determined separately for every device / build.

E.g., some distros may want OTA installation as early as possible. Therefore reserving the super partition for both A and B slots seems reasonable.

But some distros may not force users to update immediately. Therefore updater app can warn users to free some space to perform the update. In such a case, 3.2GB is more than enough.

Some distros may have 32-bit only or 64-bit only components. For such scenarios, 2.5GB may be a perfect size.

Some distros may use compressed file systems, and so on.

Would be nice to have a single definition, e.g.: 'GD_SUPER_SIZE_MB := `, and propagate it into both base/board.mk and the bootscript.

getsdimg.sh may read super.img size and adjust the total sdcard.img size based on the value.

That is why I changed the size for rpi4 only and chosen not to make a pull request in glodroid/configuration.

The increased super size does not change anything for our users. Having Android on a storage medium smaller than 16GB is not feasible anyways. Most of people use gapps and OTA will be enabled for GloDroid soon, it should be taken under consideration. If the GD_SUPER_SIZE_MB does not ship before it happens this should be merged. If this happens this patch will be removed, the compression of the image should stay

rsglobal commented 1 year ago

Ok, please add the RPI4: prefix to the patch that shouldn't go into the configuration repo.

If you don't want to use a virtual AB update, disabling it makes sense.

mikegapinski commented 1 year ago

@rsglobal Done. I am going with Virtual AB, Google made it mandatory for vendors in 13.

rsglobal commented 1 year ago

Please amend existing patches instead of adding: Added code review suggestion patch

mikegapinski commented 1 year ago

Please amend existing patches instead of adding: Added code review suggestion patch

Sure. I am used to squashing pull requests on merge, old habit

mikegapinski commented 1 year ago

I am closing this PR, it got partially merged manually and I don't have the time to do GD_SUPER_SIZE_MB right now