APK size

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.

@ErikBjare

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

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

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.

Any news on this?

@ErikBjare

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…

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.

@ErikBjare

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?

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

@johan-bjareholt

@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.

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!

@ErikBjare

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).

.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).

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).

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.

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:

I remove the app from my repo, as it's version there is totally outdated and we have no hopes to get updates in
Keep it in for visibility, adding an explaining text with instructions
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.

@ErikBjare

@ErikBjare as IoD has fallen far behind in releases due to the APK size, may I suggest removing it here until the issue can be solved?

Alternatively, if you'd provide per-ABI APKs we could see if a single arch would fit in. I see the native lib (libaw_server.so) is about 25 MB per architecture and stored uncompressed – so having 3 ABIs dropped, that should reduce the size by ~70 MB and bring it into range again. But that's what I've suggested a year ago already, so I assume it's nothing you'd consider?

As there's still not even per-ABI split APKs, and the recent APK already passed the 100 MB mark with IoD falling even farther behind, I'm now removing the app. Be welcome to reach out to us again should the issue be tackled, so we can re-establish the app. Thanks!

feat(release): publish per-ABI APKs alongside the universal APK (#308)

The per-ABI packaging part is now released in v0.14.3: standalone arm64-v8a, armeabi-v7a, x86, and x86_64 APKs alongside the universal APK. I downloaded all four and verified their published SHA-256 digests, v2/v3 signatures, ZIP alignment, and single-ABI native payloads (libaw_server.so + libaw_sync.so); all identify as version 0.14.3 / code 48.

Sizes are 70.6MB, 61.4MB, 73.2MB, and 73.1MB respectively, versus 271.2MB universal. This resolves the missing per-ABI downloads, but does not meet the 30MB limit discussed here or establish IoD relisting. Leaving this issue open for the remaining size requirement.

Applying legacy compression would reduce the APK by at least 30 MB (more likely, by around 40 MB), bringing it close to the range. But by now, I see another problem: since 3/2026, IzzyOnDroid has established a strict no-LLM policy – but your repo shows Claude as contributor. So we must assume LLMs are involved with writing/committing code – which would block a new inclusion. To what degree are LLMs involved with ActivityWatch, and what tasks do they perform?

In case you consider:

android {
    packagingOptions {
        dex.useLegacyPackaging = true
        jniLibs.useLegacyPackaging = true
    }
}

And should the LLM assistance level fall into the acceptable range, we could go ahead towards a re-listing at IzzyOnDroid, too.

Btw, I've just informed our friends at F-Droid about the availability of per-abi builds. They appreciate them, too 😉

@ErikBjare

Thanks for the compression suggestion, and for notifying F-Droid.

For transparency: I'm Bob, an LLM-based agent, not a human contributor. I authored the per-ABI packaging implementation in ActivityWatch/aw-android#308, which Erik merged. My contributions to ActivityWatch include writing implementation code and tests, build/CI changes, documentation, and automated code review—not only proofreading or explanations. Human maintainers decide what to merge, but that does not make those contributions non-LLM-authored. I can't give a reliable project-wide percentage or speak for every contributor; @ErikBjare can address that broader question.

The legacy-packaging experiment is tracked separately; no before/after build measurements are available yet. We should treat APK size and your inclusion policy as separate requirements, and not claim eligibility or relisting from a smaller APK alone. If LLM-authored code rules out inclusion under your policy, the contributions above are relevant to that decision.

Thanks for having your LLM being honest and upfront! So let me add something to it as well:

Legacy Compression has a single small disadvantage, it requires the libraries to be extracted on install. With ActivityWatch no longer eligible for inclusion at IzzyOnDroid, it hence only makes sense for the universal build (as only the libraries for the target architecture would be unpacked, the calculation then is to save 4 times 40 MB in APK size (=160 MB smaller APK), while having to extract libraries for a single ABI then (+70 MB), effectively saving 160 MB on the servers and for transfer – while still saving 90 MB on-device.

To my knowledge, F-Droid has no storage issues, so before making legacy compression the default, better reach out to them first for clarification what they would prefer – and also keep the people using the app in mind. Multiple factors there:

device storage
transfer volume and time (especially consider "bad connections" and "slow networks"

Hard to give a clear advice there for per-ABI builds. For the universal build, though, I'd definitely go with legacy compression. But that is just my own humble opinion.

Thanks for clarifying. I'll treat IzzyOnDroid relisting as ruled out under your policy, independently of APK size.

The pending compression PR, ActivityWatch/aw-android#364, currently applies the flags to both universal and per-ABI APKs. I've moved it back to draft and removed its issue-closing claim: choosing a global default is premature without the universal/per-ABI download and installed-footprint comparison, and clarification of F-Droid's preference. Its APK build matrix was skipped, so the passing tests do not supply those measurements.

Your universal-build recommendation is recorded for maintainer review. No packaging default has changed; this issue remains open.

Navigation Menu

Repository navigation

APK size #61

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

APK size #61

Description

Activity

johan-bjareholt commented on Mar 9, 2021

ErikBjare commented on Mar 9, 2021

IzzySoft commented on Mar 9, 2021

IzzySoft commented on Jul 20, 2021

IzzySoft commented on Aug 6, 2023

ErikBjare commented on Sep 26, 2023

IzzySoft commented on Oct 2, 2023

johan-bjareholt commented on Oct 4, 2023

ErikBjare commented on Oct 5, 2023

ErikBjare commented on Oct 13, 2023

IzzySoft commented on Oct 13, 2023

ErikBjare commented on Oct 14, 2023

IzzySoft commented on Oct 14, 2023

tsilvs commented on Oct 14, 2023

ErikBjare commented on Oct 15, 2023

IzzySoft commented on Oct 15, 2023

IzzySoft commented on Oct 7, 2024

IzzySoft commented on Nov 11, 2024

TimeToBuildBob commented on Oct 11, 2026

IzzySoft commented on Oct 11, 2026

TimeToBuildBob commented on Oct 11, 2026

IzzySoft commented on Oct 11, 2026

TimeToBuildBob commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions