Recently I have not been able to reduce the size of my apps. When experimenting with different features on a trial app I have tried to reduce the size of the apk to make it easier to transfer to my phone and send to people but it stays at 160mb.
I have enabled ‘compress and encrypt’.
I have disable ‘Verse on Image’ and ‘Allow saving as video’.
I have also experimented with Reading App Builder, I built a trial app with no images (it has icons but no navigation drawer or splash screen images and no other content) and just a 2 page Word document and its apk is 75mb. This also has the encrypt and compress enabled.
How can these APKs be so big, am I missing something?
I agree with @CraigN. I haven’t experiment as much as him but just now re-building an app that I created and published in January 2020. I believe the app size then was 12-13 MB but now it is 73 MB!
This is just a new testament app and I only included 3 audio files (Matthew 5-7)…the rest of the audio for download/streaming from FCBH.
TextOnImage images were still being added to the app even though the feature was turned off (and added to iOS even though the feature isn’t implemented). I have fixed this for the next release (8.2). This was 15MB
The first book collection still had “share audio clips for the selected verses” and “Create and share video clips for the selected verses” which adds FFmpeg. Removing this removed 55MB which made the app come in at 18.1MB.
Hi @lasnider, See what Chris says here. On the main menu in the Verse on Image section I had unticked both the Image and Video options. But under Books>(whatever Book Collection)>Sharing ‘create and share a verse on image’, ‘share audio clips for the selected verse’, and ‘create and share video for the selected verse’ were all ticked. So it looks like the app was being built with those features even though they were not enabled.
Check this on your project.
@ChrisHubbard thanks for these details. I have a couple clarifying questions:
Re: TextOnImage - to use this feature will add 15 MB to one’s app? Or was it 15 MB because of the included graphics/images?
Re #2 - how many MB will including just “share audio clips” add to an app (not create and share video clips)?
2 suggestions related to these questions:
It would be helpful if there was an “app size estimator” that updated as different features or resources were added so one could estimate how large the app will be when built (without needing to build the app). Along with this, features that add significant MB to the app size could be labeled as such - looking at SAB now I see that this is there for certain features already (including the share audio and create/share video but the size for just including share audio feature is not broke out).
Having the ability for users to download additional features like adding “VerseOnImage”, ShareAudio, and CreateAndShareVideo would help to keep base level app size low. I realize this type of thing would require significant changes to how apps are built and distributed and it may be something where we would need to create multiple versions of the app - one that has basic features and another that has “extra/special” features.
Re: TextOnImage:
The 15MB were the images. When the feature was turned off, the images were still being included. This has been fixed in 8.2 (out last night).
Re: #2:
The additional FFmpeg libraries (between 13 and 52 MB depending on the APK settings) are included if ANY of these are enabled:
Allow saving as a video, combining the image and audio (in Verse on Image page)
Share audio clips for the selected verses (in Book Collection > Sharing)
Create and share video clips for the selected verses (in Book Collection > Sharing)
Regarding your suggestions:
Estimating Apk Size
When building an APK, it involves compressing the resources. We don’t know the compression ratio until building the app. Also, there are libraries that are downloaded during the initial build.
An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play’s update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).
Although it might be technically feasible for apps distributed outside of the Google Play Store (I found an article how it might be done … from 3 years ago), maintaining versions of libraries for the different builds of apps generated by SAB would be very challenging and we don’t have the resources to do that. It could easily be block by the current OS and future OS updates. It has the potential to be exploited by unscrupulous developers and in my opinion it is not something we should consider (to save a few MBs).
What we should consider is enabling downloading content (not code) on demand. This has been on our feature list for a while. It would be good to have a way to download the backgrounds instead of having them always having to be packaged in with the app.