apk: read APK_VERSION_CODE env, set --numeric-version

[zebra-lucky]

add possibility to set versionCode with APK_VERSION_CODE env

[tshirtman]

Don't know if that's the solution buildozer devs want to support, but if that's to be merged, it would be better to also add documentation of the env variable somewhere.

edit: as it's directly passed to p4a maybe it would be better to directly add the env variable handling in p4a instead?

[zebra-lucky]

Don't know if that's the solution buildozer devs want to support, but if that's to be merged, it would be better to also add documentation of the env variable somewhere.

I'll try to add some docs in PR now

edit: as it's directly passed to p4a maybe it would be better to directly add the env variable handling in p4a instead?

I'll look in p4a code

[zebra-lucky]

Seems it's more logical make PR in p4a.

Question about env name arised, possibly P4A_NUMERIC_VERSION is appropriate.

I'll close this PR

[zebra-lucky]

possibly APK_NUMERIC_VERSION is more appropriate, as P4A_NUMERIC_VERSION is used in p4a_env_vars.txt in bootstraps/common/build/jni/application/src/start.c

[zebra-lucky]

Done PR to p4a:
kivy/python-for-android#2210

[AndreMiras]

@zebra-lucky and @tshirtman, first of all thanks for the PR and the discussion.
I'm just wondering, why did you introduce it via an environment variable rather than a buildozer.spec configuration?

[zebra-lucky]

I'm just wondering, why did you introduce it via an environment variable rather than a buildozer.spec configuration?

I'm using env to set separate versionCode for armeabi-v7a and arm64-v8a builds.
This solution was simple to make changes to build code and patch to buildozer.

[AndreMiras]

Thanks for clarifying, yes I understand the need of having two different versions for different arch, it makes sense. But then I feel the environment var solution is kinda hacky from a buildozer/p4a perspective

[zebra-lucky]

But then I feel the environment var solution is kinda hacky from a buildozer/p4a perspective
Maybe, these changes was possilby minimalistic for that reason.

BTW: for now we using old version of buildozer/p4a and patching code before
building was enough.

But then looking to new p4a code and see changes in numeric_version
calculations (added arch_code/min_sdk). We use four positions for version,
and that approach will not work if versionCode is Int32 (not sure about it).

[tshirtman]

There could be other solutions, but isn't p4a pretty open to using env vars to drive behaviors?

Another solutions i can think of, that would be more invasive, but also extensible to other configuration tokens: give the ability to define a command or env variable name instead of a number for version in buildozer.spec (if a value starts with a $ assume it's an env var and expand it? if the value is wrapped in ` symbols, then run it as a command)?

[AndreMiras]

Regarding the env on p4a, from what I'm ware of we only use 6 of them and all are in pythonforandroid/build.py not pythonforandroid/bootstraps/common/build/build.py so it's pretty contained. We use the following ANDROIDSDK, ANDROID_HOME, ANDROIDNDK, NDK_HOME, ANDROID_NDK_HOME and NDKAPI.
For me it would feel much cleaner to simply add the following to buildozer/targets/android.py:

diff --git a/buildozer/targets/android.py b/buildozer/targets/android.py
index a508e22..8731b3b 100644
--- a/buildozer/targets/android.py
+++ b/buildozer/targets/android.py
@@ -1024,6 +1024,7 @@ class TargetAndroid(Target):
                                            self.android_minapi)),
             ("--ndk-api", config.getdefault('app', 'android.minapi',
                                             self.android_minapi)),
+            ("--numeric-version", config.get('app', 'android.numeric_version')),
         ]
         is_private_storage = config.getbooldefault(
             'app', 'android.private_storage', True)

Untested, but you get the idea. The change is very straight forward and makes more sense to me.
But yes that would not 100% address the use case described by @zebra-lucky out of the box, but still make it possible. To me it would feel less hacky and more natural way to use buildozer. This is all we've been doing so far to me, is dealing with p4a options using the buildozer.spec file

[AndreMiras]

Meanwhile I'm also not against the idea of thinking something more generic like you suggested @tshirtman, that would make possible to override any possible parameter of p4a using environment variables. That would be more satisfying in terms of interface consistency at least, but introduce some (cyclomatic) "complexity"