build: add --android-target-sdk-version arg (defaults to android_api) #2686
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently p4a has a variable named `android_api` (set by e.g. buildozer via the `app.android.api` config key). In `AndroidManifest.xml`, both `compileSdkVersion` and `targetSdkVersion` are set to `android_api`. This PR allows setting the targetSdkVersion and compileSdkVersion independently, by adding a `--android-target-sdk-version` build arg. `compileSdkVersion` is a compilation setting used by e.g. the NDK at build-time, while `targetSdkVersion` is just a field to set in the manifest, only used at runtime (mainly in the Java world). (see e.g. https://stackoverflow.com/a/26694276 )
|
I have a corresponding patch for buildozer to allow setting this in buildozer.spec, but will wait for feedback here first. |
SomberNight
added a commit
to SomberNight/electrum
that referenced
this pull request
Oct 14, 2022
The google play store will require 31, starting 2022-11 (next month). A few commits are cherry-picked onto our forks of p4a and buildozer from upstream, but the forks are not rebased. Note that the compileSdkVersion is kept at 30, only the targetSdkVersion is bumped 30->31. closes spesmilo#8010 I am trying to upstream some relevant p4a and buildozer changes in e.g. kivy/python-for-android#2686
SomberNight
added a commit
to spesmilo/electrum
that referenced
this pull request
Oct 14, 2022
The google play store will require 31, starting 2022-11 (next month). A few commits are cherry-picked onto our forks of p4a and buildozer from upstream, but the forks are not rebased. Note that the compileSdkVersion is kept at 30, only the targetSdkVersion is bumped 30->31. closes #8010 I am trying to upstream some relevant p4a and buildozer changes in e.g. kivy/python-for-android#2686
|
bump This would be great for extra flexibility |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently p4a has a variable named
android_api(set by e.g. buildozer via theapp.android.apiconfig key). InAndroidManifest.xml, bothcompileSdkVersionandtargetSdkVersionare set toandroid_api.This PR allows setting the targetSdkVersion and compileSdkVersion independently, by adding a
--android-target-sdk-versionbuild arg.compileSdkVersionis a compilation setting used by e.g. the NDK at build-time, whiletargetSdkVersionis just a field to set in the manifest, only used at runtime (mainly in the Java world). (see e.g. https://stackoverflow.com/a/26694276 )note: my current use case is to set
targetSdkVersionto higher thancompileSdkVersion, as I am using an older NDK (r22b) that only supportscompileSdkVersion<=30, but the google play store now requirestargetSdkVersion>=31. Historically it has sometimes been the case that p4a was using an old NDK, and I had to use this trick once already a few years ago, for the same reason (but atm p4a is using a very new NDK, I am just having troubles rebasing my fork). Regardless, I believe setting the two parameters independently might have other use cases.