[Qbs] setup-android, no --system?

[Christian Gagneraud]

On Sat, 16 May 2020 at 01:23, Christian Gagneraud <chgans at gmail.com> wrote:
> As a side note, i don't install Android the same way. I use what i
> believe is the new approach: install commandline-tools first, and run
> sdk manager with a package requirement file, here is mine right now:
> build-tools;28.0.3
> ndk;21.0.6113669
> patcher;v4
> platform-tools
> platforms;android-28

Not 100% sure if i'm on the right track, but currently my product sets:
        Android.sdk.platform: "android-28"
        Android.sdk.buildToolsVersion: "28.0.3"
        Android.ndk.platform: "android-21" // not sure that's right
Because these are the official build requirements (we own the AOSP)

I think this is wrong, the project/product shouldn't dictate that, b/c
the build env provides it.
Similarly, with my upcoming keystore patch, the product sets:
        Android.sdk.keyStorePath: project.sourceDirectory +
"/build-tools/navico-release.jks"
        Android.sdk.keyStorePassword: "xxx"
        Android.sdk.keyAlias: "xxx"
        Android.sdk.keyPassword: "xxx"
I don't like this either, so either the container comes with "magic"
signing power, or the android package git repo is setup with a proper
submodule keystore provider, we have a keystore.properties file that
fully define the hosted keystore, so this is a possible solution:
  Android.sdk.keystoreProperties: "path/to/keystore/properties/file"

With both of the above solved transparently, the product just need to define:
        Android.sdk.packageName
        Android.sdk.versionName
        Android.sdk.versionCode
        Android.sdk.apkBaseName
        Android.sdk.manifestFile
Which sounds just about right to me.

Ultimately, signing, ABI, SDK, NDK, ....  selection is driven by the
container name/version that is pulled in the project's CI pipeline,
which is something the developer controls.

Chris

<troll>
We use Jenkins, you use Travis, i prefer Gitlab...
</troll>