Skip to content

Conversation

simolus3
Copy link
Contributor

@simolus3 simolus3 commented Oct 15, 2025

This is the Android follow-up to #135. Because 36 attachments to each release are apparently not enough.

The motivation is the same: For Dart build hooks, we want to be able to download a .so for each Android ABI independently instead of depending on a Gradle buildscript.
Because the file names clash with Linux builds, this also renames Linux binaries to .linux.so (used to just be .so).

@simolus3 simolus3 requested a review from rkistner October 15, 2025 16:24
Copy link
Contributor

@rkistner rkistner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy with adding these.

I do wonder - could it make sense to zip together related artifacts? For example all Android so files in one zip, or even all dynamic libraries in one zip?

@simolus3
Copy link
Contributor Author

I do wonder - could it make sense to zip together related artifacts?

Basically the way they'll be consumed by Dart in the future is that we have a Dart script that gets run as hook/build.dart android aarch64 and is supposed to output which native libraries to include for that particular combination.

It's a bit early to determine best practices here, but our approach mirrors what the Dart team is doing. E.g. for the icu4x package, prebuilt binaries are all attached to a release and the build hook downloads the file corresponding to the target ABI.

We could bundle them into a zip, but that's a tiny bit less efficient when only a subset of that is actually needed (but I think that's quite rare). It would also complicate the build process on the Dart side a bit compared to just downloading a single file per invocation (hooks for multi-abi builds run in parallel, so they might have to coordinate the download process of a zip).

What's the concern here, an ugly release page that has 40 downloadable files on it? I see that's not great, but especially for a mostly internal library like this that isn't user-facing, I don't see much of an issue either.

@simolus3 simolus3 merged commit 04bee21 into main Oct 15, 2025
31 of 33 checks passed
@simolus3 simolus3 deleted the android-libs branch October 15, 2025 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants