lambdanative icon indicating copy to clipboard operation
lambdanative copied to clipboard

Use apksigner corresponding to Android version specified in configuration

Open bkmgit opened this issue 1 year ago • 6 comments

The first matching SDK is used in: https://github.com/part-cw/lambdanative/blob/master/targets/android/build-binary#L430 which may not correspond to the Android version used for building when multiple SDKs are installed. This may lead to an older/newer apksigner program being used and lead to an incompatibility.

bkmgit avatar Jan 23 '24 10:01 bkmgit

I am sorry, but this issue and pull request don't quite make sense to me - the $ANDROIDAPI is user-determined in the SETUP, let's say ANDROIDAPI=24 or ANDROIDAPI=21. However, the version of the build-tools is fixed from its installation by the sdkmanager, e.g. build-tools;30.0.2. Also, we only support one $ANDROIDSDK path to be set in SETUP. As such adding ls -1 $ANDROIDSDK/build-tools/$ANDROIDAPI*/zipalign or $ANDROIDSDK/build-tools/$ANDROIDAPI*/apksigner will result in neither tool to be found anymore? To illustrate:

[...]
 => zipaligning..

/usr/local/android-sdk-macosx
24
/usr/local/android-sdk-macosx/build-tools/30.0.2/zipalign
ls: /usr/local/android-sdk-macosx/build-tools/24*/zipalign: No such file or directory
[...]

If you truly must set a specific version of the build-tools to use, we must introduce a new variable in SETUP for it, but I assume most users only have one set of tools. The other alternative is to hardcode it?

mgorges avatar Jan 23 '24 19:01 mgorges

Thanks. It would probably be better to have an optional variable in SETUP or users who may have more than one set of tools.

bkmgit avatar Jan 24 '24 04:01 bkmgit

I saw the updated pull request, but could you comment a bit more on why this is needed; we have always used the latest build-tools, and it works for any $ANDROIDAPI target as they are backwards compatible. Does that break something specifically for you? Thanks!

mgorges avatar Jan 24 '24 17:01 mgorges

Without this it breaks for me on Linux. Typically need to build for a variety of APIs, have build tools from 26.0.1 onwards. With the wild card, it sorts numerically in increasing order, so picks up the oldest version of build tools. The software is still functional, but I would need to modify the signing portion of the script. I may have an unusual setup, not sure how many others have several versions of build tools which would justify the extra portions in the scripts.

bkmgit avatar Jan 24 '24 17:01 bkmgit

Thanks - could you try if you only kept the latest version of the build-tools if that worked for all APIs you build for? We target different APIs frequently and, as I mentioned, only use a single build-tools version universally.

mgorges avatar Jan 24 '24 17:01 mgorges

https://developer.android.com/tools/releases/build-tools says: "You should always keep your Build Tools component updated by downloading the latest version using the Android SDK Manager. If you're using Android plugin for Gradle 3.0.0 or higher, your project automatically uses a default version of the build tools that the plugin specifies."

mgorges avatar Jan 24 '24 18:01 mgorges

Using a newer Build Tools version with older APIs works.

bkmgit avatar Feb 23 '24 12:02 bkmgit