How to handle one big repo split in multiple APKs

1

Hi, in Tux Paint we have the stamps collection that amounts about 200MB of images, sounds, metadata and sound descriptions.
https://sourceforge.net/p/tuxpaint/tuxpaint-stamps/ci/master/tree/

I’ve generated some APKs with sound descriptions(3 to 32 MB) and one APK(35MB) with the images metadata,etc.
Index of /pere/public_html/tuxpaint-stamps/20210806 all in all 13 APK files coming from the same source.

The 2 problems I am seeing in order to add them to fdroid are that currently, to generate each one of those APKs,

  1. fdroid server would have to download everything again and again.
  2. The generated zip source files are as big as the whole git repo, they would be nearly identical for each apk except the stamps.zip asset autogenerated in the prebuild step and the fdroid server would have to store all of them

Questions are
Would all this overload be acceptable?
Is there a way to tell fdroid server to reuse a download in order to compile other APKs?, or to generate different APKs from one metadata file? if possible, that would reduce drastically the network footprint.
Is there a way to tell fdroid server that the zip source file generated for one APK is also valid for other APKs?
or
Is there a way to tell the fdroid server to limit the ZIP files generation to the directory where the Android code is stored?
Any other ideas to not overload the fdroid servers?

One build entry from one metadata yml looks currently like this, I just need to adapt the versionName and gradle fields and the package_stamps.sh call to get the other APKs

  • versionName: 0.0.1-images
    versionCode: 1
    commit: b76f2331add90782bfef8908e6895c667c4e56be
    subdir: android_packager/app
    gradle:
    • Images
      prebuild:
    • cd …/
    • ./package_stamps.sh images
      scanignore:
    • android_packager/app/src/main/assets/stamps.zip
      scandelete:
    • macosx/

Thanks
Pere

2

Wesnoth and SuperTuxKart don’t include large assets in the APK, and instead download it at run time.

You could also include a small sample, or more compressed versions, or see if you can apply some optimizations to the original collection itself:

  • ogg can be downsampled, encoders like aoTuV can even achieve decent fidelity at lower bitrates
  • svg can be minified
  • png can be optimized
  • jpeg can be more compressed
  • etc.

Examples:

3

Hi, thanks for the reply,

About a downloader, yes I started some time ago to develop one, but it was too complicated for users and me at the time, maybe because I wanted to do too much fine grained control about what to download, maybe I have to revisit it to see if I can simplify it…

About my concern n2 (the size of source files, BTW tar.gz, not zip as I stated), a call to remove the unneeded stuff in the prebuild field would solve it.

Thanks
Pere

4

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.