APK size

[IzzySoft]

Looks like with the last version, APK size increased by factor 6 – due to the libaw_server.so having increased by factor 18 (from around 5M to 90M). As that exceeds the limits in my repo by factor 3 (max space per app is 30M), I had to remove v0.10 and disable auto-update.

Is there any chance to decrease APK-Size again? I don't know if whatever blew up that library could be reverted – but e.g. an armeabi-v7 only build would just fit in 30M. Should none of the two be possible, I guess it's best to remove ActivityWatch from my repo, as providing an outdated version is not a good idea.

[johan-bjareholt]

@ErikBjare Sounds like you maybe did a debug build by mistake for the APK?

[ErikBjare]

Pretty sure it's a release build, but the debug symbols might not have been stripped.

[IzzySoft]

Wow, then that lib has quite some of those. Never thought debug symbols would count for a factor 18 size increase… Thanks for digging it up! Looking forward to an APK replacement then.

BTW: It seems to be just that one library being the cause of the size increase (or at least for 98% of it), in case it matters.

[IzzySoft]

Any news on this?

[IzzySoft]

It's more than 2 years now, so I wonder if it's still worth waiting, @ErikBjare? The version in my repo is even 3 years old now…

[ErikBjare]

Just released v0.12.0, but APK size is still huge.

We now bundle the web UI directly in the libaw_server.so library binaries, which does duplicate the data 3x in the apk (but has many other benefits).

The larger issue is probably still the matter of debug symbols not being stripped, I will continue to investigate.

[IzzySoft]

It's still way to big (almost 4 times the allowed per-app size in my repo, which would be 30 MB). Doesn't look like you could get the APK size even close to that. So instead of serving a totally outdated version via my repo, I'd suggest removing the app there. What do you think, @ErikBjare?

[johan-bjareholt]

Maybe stupid question, but why can't we just run the "strip" program on libaw_server.so?

[ErikBjare]

@johan-bjareholt I ran strip and it reduced the binary by 75%, however, I think this is already being ran in the build scripts for aw-android.

[ErikBjare]

We're now building App Bundles (.aab) and including them in releases, from which you should be able to split out a .apks using bundletool, which can then be unzipped to one .apk per target platform.

If those sizes are still crazy, let me know!

[IzzySoft]

Thanks @ErikBjare! For inclusion with my repo I'd need APK files, though (my updater cannot deal with AABs). So could you also attach the APK you want me to pick (either armeabi-v7a or arm64-v8a as by your preference) directly?

(TBH, I don't even know how to "split out a .apks using bundletool – nor what an .apks might be; though for the latter I assume you'd rather meant "split out .apks", i.e. the separate APK files; I don't even have bundletool available here).

[ErikBjare]

.apks is just a zip archive of APKs (which in turn are zip archives themselves).

bundletool is part of the Android SDK. I don't have any more experience with it than you, so you're going to have to figure it out yourself (shouldn't be hard).

[IzzySoft]

I've checked build-tools and platform-tools, none of them contain bundletool. Yes, it can be obtained from Github as a .jar, but the documentation describes it as an executable with no hints on installing it (guess you'd need a wrapper to call something like java -jar bundletool.jar). Still, it would need time to figure out how to use it, and then even more time to integrate it with my framework so it could be used for auto-updates – time I currently do not have. It's "on my list", but I cannot even guess an ETA.

So if you could provide the per-ABI APK(s), that would speed up things a lot. As your app is already in my repo (last updated there 3 years ago), even doing that "every now and then" (for the "stable" releases, no need to do it for the pre-releases unless you can automate it) would help. You probably have the full Android SDK installed, I have not. I do what I can, but there are limits: my repo is a one-man-show, and I have plenty of other "volunteer work" at my hands…

Taking a quick look: I've unzipped your 107 MB APK, removed all lib/<abi> except for one, and zipped the resulting structures again:

• armeabi-v7a: 12 MB
• arm64-v8a: 12.5 MB

Strange. With native libs for each ABI around 27 MB, I wouldn't have expected that much difference. Must be something else… Ah, some files must just be "stored" (uncompressed) as unzip and zip the full APK comes down to just 37 MB. Checking again and meeting my suspicion: the native libs are just "stored", too, so it's their 4x27 MB making it that size (yes, I think I know why they are "just stored": so Android does not need to unpack them on installation but using them directly from the APK, right?). So that would add

• 16 MB to armeabi-v7a making it about 28 MB
• 19 MB to arm64-v8a making it about 31.5 MB

(writing "about" as some other, smaller files are also just "stored"). Which means I could pick the armeabi-v7a build as it would still be inside my repo's limits of 30 MB per app (apologies for the lengthy post – I just wanted to make sure if the efforts on either end would yield results we can use – looks like they would).

[ErikBjare]

Okay, so constructing APKs for distribution from AABs with bundletool seems more complicated than I thought.

Unzipping the apk, removing ABIs for other than your target platform, and rezipping (like you did) seems the quickest way.

---

I've checked build-tools and platform-tools, none of them contain bundletool. Yes, it can be obtained from Github as a .jar, but the documentation describes it as an executable with no hints on installing it

Oops, sorry about that. Yeah, you just run it with java -jar bundletool.jar, nothing strange there.

I managed to get it running in 2bbdaa7, it spits out a tree like this:
(NOTE: ran on an ~150MB aw-android.aab from Oct 8th I had nearby, so numbers don't reflect the most recent release)

---

Splitting with a specific device configuration yields this:

---

I do what I can, but there are limits: my repo is a one-man-show, and I have plenty of other "volunteer work" at my hands…

You and me both! :)

I don't really personally care about the APK sizes, and I think this is the best I can do with the knowledge I have, so I'm going to stop working on improving it for now, since it feels like I'm just treading water here.

PRs welcome, as always.

[IzzySoft]

Thanks for the analysis, Erik! So with that "full APK" it would mean around 70+ MB for arm64 (32bit will not be that much different). Which means we cannot even hope getting it below 50 MB with some optimization – not to speak of the 30 MB per-app limit in my repo. Unless those native libs can be compressed (which then would result in a bigger install size, as Android would need to unpack them). Not the news we had hoped for.

So what path forward do you suggest? Options would include:

1. I remove the app from my repo, as it's version there is totally outdated and we have no hopes to get updates in
2. Keep it in for visibility, adding an explaining text with instructions
3. Trying a single-arch build (you could use ABI filters for that) with the libs compressed and updating to that

My preferences would be 3 then 1 – but 3 would mean some more (initial) work for you setting up the build and getting the APK attached. 2 would work but be a bit strange with a 3 years old version that doesn't get any younger.

And sure, PRs would be great – but I couldn't provide this one (I have no experience with that to speak of; all I can offer are "wise words"). e could of course combine that with 2 for a while: Opening an issue here with "help needed" and linking that from the app description in my repo, wait half a year to see if it yields something, and decide then.