Remove native libs

[lsd-cat]

This PR aims to remove all the native dependencies in Bugbane, if possible. This shrinks the APK sizes, as we do not need architecture specific code, and improves future reproducibility.

The biggest library was Conscrypt: I reverted back to the libadb-android instructions on using reflection (HiddenAPIBypass). At first I thught that required a native lib anyway, to bridge the NDK methods to the SDK, but when analyzing the APK, it doesn't look like that is the case.

Second, I'm excluding from the deps graph a native component of the graphics toolkit. I don't think we use it, but I should do extensive testing to check that it doesn't break anything.

Lastly, there's the spake2 implementation. In theory libadb-android uses spake2-java, but the library has also a native android implementation that is used by default. I tried to swap it, but it did not work and will investigate more, see: MuntashirAkon/libadb-android#22

Also with this PR the release APK shrinks to half its size:

[TheZ3ro]

just one thing, do we know if there are problems pushing applications that use the "HiddenAPIBypass" on Google Play Store?
I mean, will Google approve apps that use those?

[lsd-cat]

AFAIK that's not an issue, it seems that Shizuku uses it also on the play store version and it seems bundled with many more apps. It also seems to me that what we are bypassing is not a security boundary, but the lack of a stable API (which is actually exposed in our case from newer API levels: ie on Android 14/15/16 the bypass is not needed because Conscrypt is exposed),

[rocodes]

This is the explanation on integration from the shizuku developer: https://github.com/LSPosed/AndroidHiddenApiBypass?tab=readme-ov-file#integration. AIUI you't can integrate the way you have without getting blocked by the playstore, and I think even with lsposed all of this is a ~gray area (i.e. if your app gets carefully reviewed they could decide to enforce a standard, or if apps that don't report internal dependencies get blocked in the future then that would wipe out this approach). So there's the option of following their integration guide, but also, if we're worried about perception/user trust, it might be better to err on the side of caution and avoid this approach.

[lsd-cat]

I think you are both right, I was excited about this because the multi-arch conscrypt is like 70% of the final size of the app, and given the outreach we'd like to have, it seemed nice to start shrinking. While I see the play store risks, it also seemed acceptable since what you are doing in the end is using the already existing system components. Maybe we can have a lighter APK/fdroid release and then the Play Store one, which maybe also split the apk by arch anyway?

[lsd-cat]

For more context:

• Android ships a native SSL library (conscrypt), accessible as a public API since API level 29 (Android 10+) (Source)
• ADB requires to bundle the SPAKE2 agreement into the TLS agreement: to do so it needes a low level access to the TLS session key via (
• The API to do that natively is available since API Level 31 (Android 12+), see exportKeyingMaterial
• There is no other way on API Level 30 (Android 11) to use exportKeyingMaterial without reflection. The alternative is to reship the entire TLS stack (org.conscrypt indeed).

In short, it's pretty annoying because we would have to keep shipping Conscrypt, which is like 70+% of the size of the final multi arch APK, just for that single API only on Android 11...

[rocodes]

I'm sorry, I hate to be a killjoy :'( So just to make sure that I understand the problem: the problem is that you can't split by architecture while maintaining control of signing keys (as opposed to letting fdroid build for you) so you have to build one fat crosscompatible apk, is that accurate? So you wanted no native libs to avoid this entirely?

I was looking at some split abi efforts: eg https://f-droid.org/packages/com.junkfood.seal/ , introduced here https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11980/diffs - but is that only possible if fdroid builds the packages?

[lsd-cat]

So, here's a possibility: HiddenApiBypass is general purpose, detected, and implements a plethora of methods to have support for a lot of Android versions. If my understanding is correct, we need to export only conscrypt (or a subset of it) on Android 11. I can try extracting for HiddenApiBypass some code to re-export only conscrypt, and only the method that is needed in Android 11, and gate that behind an API level check. I should be able to shrink HiddenApiBypass to the minimum, and to a reviewer eye it would be clear what is happening. I'm not sure it is worth pursuing though, if we still think that would be sketchy on our part (of course in case of negative review even when doing that, it would be wasted time of me, but I'm open to that)