Cwa-app-android: Reduce size of compiled / uploaded app

[IT-Cru]

Current Implementation

In Google PlayStore the Corona-Warn-App is displayed with a size of 31 MB.
In Apple App Store the Corona-Warn-App is displayed with a size of 18,9 MB.

Suggested Enhancement

I think many people will not understand why a simple app which will not track any personal data or something else from them is so big. Also not so powerful devices should be supported, because not all people have latest power devices. I think many users will not install an app with such a huge size.

• [ ] Reduce size of production required assets like images, icons, logos
• [ ] Remove non-production required assets from app source
• [ ] Remove all develop / test related stuff from production app
• [ ] Reduce usage of not really required libs or use smaller ones
• [ ] Check used install package type Android App Bundles or APK
• [ ] Maybe optimize CI jobs / pipelines

Expected Benefits

More people will install a clean and smaller app.

Internal Tracking ID: EXPOSUREAPP-1872

[SebastianWolf-SAP]

The app simply needs the space right now. If you have concrete steps for improvements, contributions are welcome. But for now, we close this issue as too abstract.

Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

[corneliusroemer]

Some of the recommendations were quite explicit: Reduce size of assets?

And yes, 30MB is big. Once it's running smoothly, try to get it down in a week or two.

[Phoenix616]

@SebastianWolf-SAP please stop closing issues that aren't resolved, thanks.

[corneliusroemer]

@SebastianWolf-SAP Please don't add wontfix prematurely. Surely you will work on this app for the next few months while the pandemic is ongoing and continue to improve it.

You did a good job getting it out quickly. Now the optimisation begins.

Got reopened, rightly so, as #527

[ironjan]

@SebastianWolf-SAP please remember the first few weeks after the cwa-repositories were published step by step: Lots of issues were closed with "we'll do that later, please wait". Soon after, lots of duplicates were created for the closed issues - most likely because the original problem still persisted and there were no open issues that tracked it. For one thing, this causes unnecessary work for the repository maintainers. But worse: it may lead to frustration on the side of contributors.

In this sense, I would suggest to close #527 as duplicate of #482 and reopen #482 since

• the issue actually lists "concrete steps for improvements" (as requested here) and
• "contributions are welcome" (as written here).

---

@IT-Cru could you add in the benefit mentioned in #527 ("support for budget phones with small internal space") in https://github.com/corona-warn-app/cwa-app-android/issues/482#issue-639403794? Perhaps you could also use a task list instead of a bullet list.

https://github.com/corona-warn-app/cwa-app-android/issues/527#issuecomment-644682489 also asks if the app currently uses Android App Bundle as deployment method instead of APK. Perhaps this could also be added to the suggested enhancements.

[IT-Cru]

Switched from bullet to task list and little re-ordering.
Added check for used package type.

@SebastianWolf-SAP: Are there any shared assets / components between Android and Apple repo?

Maybe I've a little more time on Friday or upcoming weekend with bad weather to dive deeper into code and repo structure.

[R4md4c]

I've taken a deeper look on why the app is too big for what it does, and found out that's because of the native libs that are getting shipped for every architecture in a single apk, that means an arm device would get an x86 lib binary even though it is not needed at all.

To remedy this we have two options AFAIK:

1. App Bundles (the hardest) Obviously not possible with the current code structure as it requires some modularization steps to be taken for the project which I'm not sure if the maintainers have time for that or not.
   Which are like a blue-print apk that Google Play will use to generate multiple apks that fits your device specs exactly (e.g. GP will only serve just the files necessary that fits your screen density, architecture and language hence will result in even less download size than Option 2).
   I followed the steps in this guide and tried them out with a Galaxy_Nexus_API_23 emulator, and found out that a total of 14 MBs of apk size got installed to the emulator vs 17.2 MB in Option 2.

1. Using APK splits (the easiest) which I tried it out as an experiment and resulted in three different apks:

• Corona-Warn-App-device-arm64-v8a-release-unsigned.apk size 16.3 MB
• Corona-Warn-App-device-armeabi-v7a-release-unsigned.apk size 14.4 MB
• Corona-Warn-App-device-x86_64-release-unsigned.apk size 17.2 MB

That means if a user has a phone with one of these architectures, he'd just download the corresponding apk to his architecture hence saving almost 50% of the current download size.

I could try to open a PR for option 2, but not sure if it would get accepted by the maintainers or not.

[ironjan]

@R4md4c Could you elaborate a little bit on what steps would be necessary for option 1? I understood that app bundles would enable Google Play to generate apks for the different native variants but maybe this was too naive. Mainly for my curiosity; however it may be interesting for someone that would like to pick up the bundle variant.

[R4md4c]

@ironjan Thanks to your question, it made me read more in depth regarding the app bundle, and turned out that changing the code structure is only necessary if you're going to support Dynamic Features (which are features that are deferred until the user explicitly requests them), which I don't think it applies to the use case of the corona app. I'll edit my comment above to reflect on my findings.

[corneliusroemer]

The app simply needs the space right now. If you have concrete steps for improvements, contributions are welcome. But for now, we close this issue as too abstract.

Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

@SebastianWolf-SAP 's reasons for closing the issue are no longer valid.

There are now very concrete proposals on how to reduce size to a third without much ado.

@R4md4c 's post shows clearly why it's a bad idea to close issues quickly even if there are no concrete solutions presented. They may appear later once someone sees there is an issue and starts looking. Point in case. So please, maintainers, stop closing issues as quickly as you're doing right now. You can add labels to them as much as you like, but don't silence the community when it thinks there's an issue.

Please reopen the issue or decide that #606 is better instead. If this issue gets reopened, I will close #606.