fix: bundletool.jar download is sometimes corrupt (need to verify artifacts)

[k3v1n-uncle]

[eseidel]

That file path should be exactly https://github.com/google/bundletool/releases/download/1.15.6/bundletool-all-1.15.6.jar

https://github.com/shorebirdtech/shorebird/blob/6aa88e3355507cde91878515803de36fd9717392/packages/shorebird_cli/lib/src/cache.dart#L297

eseidel@erics-mbp handbook % md5 ~/.shorebird/bin/cache/artifacts/bundletool/bundletool.jar MD5 (/Users/eseidel/.shorebird/bin/cache/artifacts/bundletool/bundletool.jar) = d91230a986d4a990e7bb69351b9e9464

I would expect our artifact downloading to be robust against failures, but maybe it isn't? Can you confirm if the file at your path has that md5?

[eseidel]

Hmm, yeah, I don't see any code to validate that the integrity of our artifact downloads. That should be simple to add (and something we should do anyway), which presumably would catch this kind of bug (assuming the file in that location isn't the md5 above).

Once you've checked the md5, shorebird clean should resolve the issue.

[eseidel]

If the md5 does match, then my next theory would be that the java version shorebird is finding isn't the right one (or is too old).

[k3v1n-uncle]

That file path should be exactly https://github.com/google/bundletool/releases/download/1.15.6/bundletool-all-1.15.6.jar

https://github.com/shorebirdtech/shorebird/blob/6aa88e3355507cde91878515803de36fd9717392/packages/shorebird_cli/lib/src/cache.dart#L297

eseidel@erics-mbp handbook % md5 ~/.shorebird/bin/cache/artifacts/bundletool/bundletool.jar MD5 (/Users/eseidel/.shorebird/bin/cache/artifacts/bundletool/bundletool.jar) = d91230a986d4a990e7bb69351b9e9464

I would expect our artifact downloading to be robust against failures, but maybe it isn't? Can you confirm if the file at your path has that md5?

my bundletool.jar md5 is 241d9b5d028994b645f0becd330e0e47,i will download 1.15.6.jar and try it later

[k3v1n-uncle]

Hmm, yeah, I don't see any code to validate that the integrity of our artifact downloads. That should be simple to add (and something we should do anyway), which presumably would catch this kind of bug (assuming the file in that location isn't the md5 above).

Once you've checked the md5, shorebird clean should resolve the issue.

the 1.15.6.jar is ok

[k3v1n-uncle]

If the md5 does match, then my next theory would be that the java version shorebird is finding isn't the right one (or is too old).

how can i only build arm version,i dont need others,because the apk size is too big

[eseidel]

If the md5 does match, then my next theory would be that the java version shorebird is finding isn't the right one (or is too old).

how can i only build arm version,i dont need others,because the apk size is too big

If you're distributing via the stores, then they do the splitting for you automatically.

It looks like we don't currently support the --split-per-abi flag: https://github.com/shorebirdtech/shorebird/issues/1141

But bundletool should be able to pull out a single-abi apk from an aab: https://developer.android.com/guide/app-bundle

[eseidel]

@erickzanardo if there aren't obvious support bugs to work on Monday morning, this is probably a good next bug to chew one. The end result we want is something that verifies that the artifact made it down in one piece. We could look what Flutter tool does if needed.

[eseidel]

The extreme version of this is probably having checksum files in in our artifacts, that we pull down and expect the checksums of the artifacts once extracted to match? But there might be something simpler.

What I suspect went wrong here was that the process died while extracting bundletool.jar or somehow otherwise corrupted the file, but when we next launched we didn't realize it wasn't completely downloaded/extracted and got confused?

[erickzanardo]

Sounds good