ndk
ndk copied to clipboard
android
[DOC] document behavior and workarounds for executables in APKs
URL None yet.
Problem
Executables in APKs are supported but there are a number of gotchas (the biggest being that if your binary is not named lib*.so it won't be installed by packagemanager). We should document the things people need to know to use these, and also recommend simpler alternatives.
See https://issuetracker.google.com/152645643.
I'd say that the biggest gotcha is that these executables require android:extractNativeLibs=true contrary to the recommendations. Especially with bundles, where the default is false.
And there is no way to do partial extract.
Also, such executable will not find app-local shared libraries if it depends on them, see https://github.com/tanersener/mobile-ffmpeg/issues/457#issuecomment-650722462.
+1 for properly documenting this. At times working on my case, I felt like I was up the creek without a paddle trying to piece together information on random websites, issues, and StackOverflow answers (and it doesn't help being an intern never exposed to Android development before this summer). A solid, official documentation section would be awesome. Those who understand the details better can draft the docs, but I'm willing to offer feedback on the drafts from the novice perspective.
Tangential to that, can we also loosen or fix these restrictions so we don't need so many workarounds? Even if the fixes are only available on API 31+, then that means that sometime a few years down the road, a future developer who doesn't see value in supporting ancient APIs like 29 and 30 can take advantage of these fixes and these workarounds can eventually become a historical note. Just because the fixes won't be valuable now doesn't by itself mean that it's not worth fixing now.
Tangential to that, can we also loosen or fix these restrictions so we don't need so many workarounds? Even if the fixes are only available on API 31+, then that means that sometime a few years down the road, a future developer who doesn't see value in supporting ancient APIs like 29 and 30 can take advantage of these fixes and these workarounds can eventually become a historical note. Just because the fixes won't be valuable now doesn't by itself mean that it's not worth fixing now.
I think that decision is owned by a different team so convincing us won't help much :) You'd need to file a platform bug for that.
Where would I file that bug? I'm not familiar with the organization of the bazillion issue trackers floating around. :P (I feel like I've bounced around to several.)
Yeah, understood :) https://source.android.com/setup/contribute/report-bugs#platform, probably in the system category. Please post the URL here when you file it so I can CC myself.
I believe the best practice right now to set android:extractNativeLibs to false. If set it to true you end up having 2 versions of the native library (1 compressed and 1 decompressed), this is very bad for user storage and for your app as well. They always consider removing app that takes too much storage of their phone
I believe the best practice right now to set android:extractNativeLibs to false. If set it to true you end up having 2 versions of the native library (1 compressed and 1 decompressed), this is very bad for user storage and for your app as well. They always consider removing app that takes too much storage of their phone
This is all true for libraries, but not for executables, which is what this issue is about. Executables cannot be executed from the APK and must be extracted. And using executables cannot always be avoided (for example, in some cases when using third-party programs).
@jcgoble3 https://github.com/vvb2060/curl-android/blob/master/tool/src/main/java/io/github/vvb2060/ndk/curl/MainActivity.java This is an example of executing an executable file in APK without extract it.
I no longer have an interest in this. I encountered this in a specific use case during an internship that I left a long time ago. I don't have any current need for this and don't anticipate any future need for this.