* [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
@ 2025-07-02 9:10 Shan Shaji
2025-07-03 14:03 ` Dominik Csapak
2025-07-03 14:36 ` [pve-devel] applied: " Thomas Lamprecht
0 siblings, 2 replies; 13+ messages in thread
From: Shan Shaji @ 2025-07-02 9:10 UTC (permalink / raw)
To: pve-devel
The current target API level is 34(Android 14). According to
google play requirements the target API level should be
within one year of latest Android release.
To fix the issue update `compileSdkVersion` to 35 (Android 15)
and `targetSdkVersion` to API level 36 (Android 16). The
`compileSdkVersion` was not updated to API level 36 as
`biometric_storage` [5] plugin's compileSdk is 35.
Plugins (pve_flutter_frontend):
- flutter_inappwebview [0]
- shared_preference [1]
- path_provider [2]
- url_launcher [3]
Plugins (proxmox_login_manager):
- shared_preference [4]
- biometric_storage [5]
[0] - https://pub.dev/packages/flutter_inappwebview/versions/6.0.0#requirements
[1] - https://pub.dev/packages/shared_preferences/versions/2.3.4
[2] - https://pub.dev/packages/path_provider/versions/2.1.5
[3] - https://pub.dev/packages/url_launcher/versions/6.3.1
[4] - https://pub.dev/packages/shared_preferences/versions/2.2.3
[5] - https://github.com/authpass/biometric_storage/blob/63c3dc3cd74729c78e4fc2de54b36e0db9540cbf/android/build.gradle#L34
Signed-off-by: Shan Shaji <s.shaji@proxmox.com>
---
The version was updated as we received an email from Google play
to update the target API level and release a new version before
31st August 2025.
The exact versions of the plugins are taken from the `.lock` file
as we are using the caret versioning for our dependencies in
`pubspec.yaml`.
android/app/build.gradle | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/android/app/build.gradle b/android/app/build.gradle
index bcb364d..a749e46 100644
--- a/android/app/build.gradle
+++ b/android/app/build.gradle
@@ -44,7 +44,7 @@ def keystoreSecret = System.getenv('PROXMOX_APP_KEYSTORE_SECRET')
: keystoreProperties['keyPassword']
android {
- compileSdkVersion 34
+ compileSdkVersion 35
namespace "com.proxmox.app.pve_flutter_frontend"
sourceSets {
@@ -55,7 +55,7 @@ android {
defaultConfig {
applicationId namespace
minSdkVersion 23
- targetSdkVersion 34
+ targetSdkVersion 36
versionCode flutterVersionCode.toInteger()
versionName flutterVersionName
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
--
2.39.5
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-02 9:10 [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36 Shan Shaji
@ 2025-07-03 14:03 ` Dominik Csapak
2025-07-03 14:20 ` Tim Marx
2025-07-03 14:25 ` Thomas Lamprecht
2025-07-03 14:36 ` [pve-devel] applied: " Thomas Lamprecht
1 sibling, 2 replies; 13+ messages in thread
From: Dominik Csapak @ 2025-07-03 14:03 UTC (permalink / raw)
To: Proxmox VE development discussion, Shan Shaji; +Cc: Thomas Lamprecht
LGTM, and built + tested fine here,
but maybe someone else also wants to take a look too... (@thomas?)
Does it even make sense to set the targetSdkVersion higher than the compiled one?
Otherwise, consider this
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
On 7/2/25 11:10, Shan Shaji wrote:
> The current target API level is 34(Android 14). According to
> google play requirements the target API level should be
> within one year of latest Android release.
>
> To fix the issue update `compileSdkVersion` to 35 (Android 15)
> and `targetSdkVersion` to API level 36 (Android 16). The
> `compileSdkVersion` was not updated to API level 36 as
> `biometric_storage` [5] plugin's compileSdk is 35.
>
> Plugins (pve_flutter_frontend):
> - flutter_inappwebview [0]
> - shared_preference [1]
> - path_provider [2]
> - url_launcher [3]
>
> Plugins (proxmox_login_manager):
> - shared_preference [4]
> - biometric_storage [5]
>
> [0] - https://pub.dev/packages/flutter_inappwebview/versions/6.0.0#requirements
> [1] - https://pub.dev/packages/shared_preferences/versions/2.3.4
> [2] - https://pub.dev/packages/path_provider/versions/2.1.5
> [3] - https://pub.dev/packages/url_launcher/versions/6.3.1
> [4] - https://pub.dev/packages/shared_preferences/versions/2.2.3
> [5] - https://github.com/authpass/biometric_storage/blob/63c3dc3cd74729c78e4fc2de54b36e0db9540cbf/android/build.gradle#L34
>
> Signed-off-by: Shan Shaji <s.shaji@proxmox.com>
> ---
>
> The version was updated as we received an email from Google play
> to update the target API level and release a new version before
> 31st August 2025.
>
> The exact versions of the plugins are taken from the `.lock` file
> as we are using the caret versioning for our dependencies in
> `pubspec.yaml`.
>
> android/app/build.gradle | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/android/app/build.gradle b/android/app/build.gradle
> index bcb364d..a749e46 100644
> --- a/android/app/build.gradle
> +++ b/android/app/build.gradle
> @@ -44,7 +44,7 @@ def keystoreSecret = System.getenv('PROXMOX_APP_KEYSTORE_SECRET')
> : keystoreProperties['keyPassword']
>
> android {
> - compileSdkVersion 34
> + compileSdkVersion 35
> namespace "com.proxmox.app.pve_flutter_frontend"
>
> sourceSets {
> @@ -55,7 +55,7 @@ android {
> defaultConfig {
> applicationId namespace
> minSdkVersion 23
> - targetSdkVersion 34
> + targetSdkVersion 36
> versionCode flutterVersionCode.toInteger()
> versionName flutterVersionName
> testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-03 14:03 ` Dominik Csapak
@ 2025-07-03 14:20 ` Tim Marx
2025-07-03 14:28 ` Thomas Lamprecht
2025-07-03 14:25 ` Thomas Lamprecht
1 sibling, 1 reply; 13+ messages in thread
From: Tim Marx @ 2025-07-03 14:20 UTC (permalink / raw)
To: Proxmox VE development discussion, Dominik Csapak, Shan Shaji
Cc: Thomas Lamprecht
> Dominik Csapak <d.csapak@proxmox.com> hat am 03.07.2025 16:03 CEST geschrieben:
>
>
> LGTM, and built + tested fine here,
> but maybe someone else also wants to take a look too... (@thomas?)
>
> Does it even make sense to set the targetSdkVersion higher than the compiled one?
>
I don't think so, this is the version the app should be tested against.
https://developer.android.com/guide/topics/manifest/uses-sdk-element?hl=en
The only combination that is probably valid, would be a lower targetsdkversion than the compilesdkversion.
> Otherwise, consider this
>
> Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
> Tested-by: Dominik Csapak <d.csapak@proxmox.com>
>
> On 7/2/25 11:10, Shan Shaji wrote:
> > The current target API level is 34(Android 14). According to
> > google play requirements the target API level should be
> > within one year of latest Android release.
> >
> > To fix the issue update `compileSdkVersion` to 35 (Android 15)
> > and `targetSdkVersion` to API level 36 (Android 16). The
> > `compileSdkVersion` was not updated to API level 36 as
> > `biometric_storage` [5] plugin's compileSdk is 35.
> >
> > Plugins (pve_flutter_frontend):
> > - flutter_inappwebview [0]
> > - shared_preference [1]
> > - path_provider [2]
> > - url_launcher [3]
> >
> > Plugins (proxmox_login_manager):
> > - shared_preference [4]
> > - biometric_storage [5]
> >
> > [0] - https://pub.dev/packages/flutter_inappwebview/versions/6.0.0#requirements
> > [1] - https://pub.dev/packages/shared_preferences/versions/2.3.4
> > [2] - https://pub.dev/packages/path_provider/versions/2.1.5
> > [3] - https://pub.dev/packages/url_launcher/versions/6.3.1
> > [4] - https://pub.dev/packages/shared_preferences/versions/2.2.3
> > [5] - https://github.com/authpass/biometric_storage/blob/63c3dc3cd74729c78e4fc2de54b36e0db9540cbf/android/build.gradle#L34
> >
> > Signed-off-by: Shan Shaji <s.shaji@proxmox.com>
> > ---
> >
> > The version was updated as we received an email from Google play
> > to update the target API level and release a new version before
> > 31st August 2025.
> >
> > The exact versions of the plugins are taken from the `.lock` file
> > as we are using the caret versioning for our dependencies in
> > `pubspec.yaml`.
> >
> > android/app/build.gradle | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/android/app/build.gradle b/android/app/build.gradle
> > index bcb364d..a749e46 100644
> > --- a/android/app/build.gradle
> > +++ b/android/app/build.gradle
> > @@ -44,7 +44,7 @@ def keystoreSecret = System.getenv('PROXMOX_APP_KEYSTORE_SECRET')
> > : keystoreProperties['keyPassword']
> >
> > android {
> > - compileSdkVersion 34
> > + compileSdkVersion 35
> > namespace "com.proxmox.app.pve_flutter_frontend"
> >
> > sourceSets {
> > @@ -55,7 +55,7 @@ android {
> > defaultConfig {
> > applicationId namespace
> > minSdkVersion 23
> > - targetSdkVersion 34
> > + targetSdkVersion 36
> > versionCode flutterVersionCode.toInteger()
> > versionName flutterVersionName
> > testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-03 14:03 ` Dominik Csapak
2025-07-03 14:20 ` Tim Marx
@ 2025-07-03 14:25 ` Thomas Lamprecht
2025-07-03 14:45 ` Dominik Csapak
1 sibling, 1 reply; 13+ messages in thread
From: Thomas Lamprecht @ 2025-07-03 14:25 UTC (permalink / raw)
To: Dominik Csapak, Proxmox VE development discussion, Shan Shaji
Am 03.07.25 um 16:03 schrieb Dominik Csapak:
> LGTM, and built + tested fine here,
> but maybe someone else also wants to take a look too... (@thomas?)
>
> Does it even make sense to set the targetSdkVersion higher than the compiled one?
Yeah, that can be fine, the targetSdkVersion basically denotes what (API)
version one tested the App against and signals Android that it doesn't need
to enable any backward compat handling as long as the Android (API) version
is equal or lower than the provided targetSdkVersion.
Such compat handling could e.g. be w.r.t. App permissions, if there are
newer more granular one, or the default set got reduced it might break older
apps, so that is only enabled if the app signals that it supports it,
naturally with some time window to not allow uploading an app (update) to
avoid that this can be misused.
The compileSdkVersion is the API the app is compiled against and thus
one can only actively use newer APIs if one increases this. Most of the time
one want's to have those two in sync, but it's fine if the targetSdkVersion
gets higher, it just cannot be lower than the compiled one.
>
> Otherwise, consider this
>
> Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
> Tested-by: Dominik Csapak <d.csapak@proxmox.com>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-03 14:20 ` Tim Marx
@ 2025-07-03 14:28 ` Thomas Lamprecht
0 siblings, 0 replies; 13+ messages in thread
From: Thomas Lamprecht @ 2025-07-03 14:28 UTC (permalink / raw)
To: Proxmox VE development discussion, Tim Marx, Dominik Csapak, Shan Shaji
Am 03.07.25 um 16:20 schrieb Tim Marx:
>> Dominik Csapak <d.csapak@proxmox.com> hat am 03.07.2025 16:03 CEST geschrieben:
>>
>>
>> LGTM, and built + tested fine here,
>> but maybe someone else also wants to take a look too... (@thomas?)
>>
>> Does it even make sense to set the targetSdkVersion higher than the compiled one?
>>
> I don't think so, this is the version the app should be tested against.
> https://developer.android.com/guide/topics/manifest/uses-sdk-element?hl=en
>
> The only combination that is probably valid, would be a lower targetsdkversion than the compilesdkversion.
You probably meant to say invalid - but yes, that combination cannot work.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* [pve-devel] applied: [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-02 9:10 [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36 Shan Shaji
2025-07-03 14:03 ` Dominik Csapak
@ 2025-07-03 14:36 ` Thomas Lamprecht
1 sibling, 0 replies; 13+ messages in thread
From: Thomas Lamprecht @ 2025-07-03 14:36 UTC (permalink / raw)
To: pve-devel, Shan Shaji
On Wed, 02 Jul 2025 11:10:56 +0200, Shan Shaji wrote:
> The current target API level is 34(Android 14). According to
> google play requirements the target API level should be
> within one year of latest Android release.
>
> To fix the issue update `compileSdkVersion` to 35 (Android 15)
> and `targetSdkVersion` to API level 36 (Android 16). The
> `compileSdkVersion` was not updated to API level 36 as
> `biometric_storage` [5] plugin's compileSdk is 35.
>
> [...]
Applied, thanks!
[1/1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
commit: a2bcbdfb809e4ab9a39224296eb6af88eee45a51
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-03 14:25 ` Thomas Lamprecht
@ 2025-07-03 14:45 ` Dominik Csapak
2025-07-03 14:56 ` Thomas Lamprecht
0 siblings, 1 reply; 13+ messages in thread
From: Dominik Csapak @ 2025-07-03 14:45 UTC (permalink / raw)
To: Thomas Lamprecht, Proxmox VE development discussion, Shan Shaji
On 7/3/25 16:25, Thomas Lamprecht wrote:
> Am 03.07.25 um 16:03 schrieb Dominik Csapak:
>> LGTM, and built + tested fine here,
>> but maybe someone else also wants to take a look too... (@thomas?)
>>
>> Does it even make sense to set the targetSdkVersion higher than the compiled one?
>
> Yeah, that can be fine, the targetSdkVersion basically denotes what (API)
> version one tested the App against and signals Android that it doesn't need
> to enable any backward compat handling as long as the Android (API) version
> is equal or lower than the provided targetSdkVersion.
>
> Such compat handling could e.g. be w.r.t. App permissions, if there are
> newer more granular one, or the default set got reduced it might break older
> apps, so that is only enabled if the app signals that it supports it,
> naturally with some time window to not allow uploading an app (update) to
> avoid that this can be misused.
>
> The compileSdkVersion is the API the app is compiled against and thus
> one can only actively use newer APIs if one increases this. Most of the time
> one want's to have those two in sync, but it's fine if the targetSdkVersion
> gets higher, it just cannot be lower than the compiled one.
sorry to continue this, but there is something I don't really understand here
(not that I want to say you're wrong, just wanting to understand)
how can my 'target sdk version' be higher than my 'compiled sdk version' ?
in that, how can i target sdks that are newer than the one i compile against?
wouldn't that mean that the old sdk (e.g. 35 in our case) must have
knowledge about the next version ?
e.g i found an article[0] about those versions (not sure how good or representative it is)
that explicitely says:
---
If you made it through the bolded notes, you’ll notice a relationship between the three values:
minSdkVersion <= targetSdkVersion <= compileSdkVersion
---
which would mean that my target version can't be higher than my compile version...
that said, the app built successfully with these values, and I noticed no problem
with either android 15 and 16 (in an emulator...)
0:
https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-03 14:45 ` Dominik Csapak
@ 2025-07-03 14:56 ` Thomas Lamprecht
2025-07-03 15:18 ` Tim Marx
0 siblings, 1 reply; 13+ messages in thread
From: Thomas Lamprecht @ 2025-07-03 14:56 UTC (permalink / raw)
To: Dominik Csapak, Proxmox VE development discussion, Shan Shaji
Am 03.07.25 um 16:45 schrieb Dominik Csapak:
> On 7/3/25 16:25, Thomas Lamprecht wrote:
>> Am 03.07.25 um 16:03 schrieb Dominik Csapak:
>>> LGTM, and built + tested fine here,
>>> but maybe someone else also wants to take a look too... (@thomas?)
>>>
>>> Does it even make sense to set the targetSdkVersion higher than the compiled one?
>>
>> Yeah, that can be fine, the targetSdkVersion basically denotes what (API)
>> version one tested the App against and signals Android that it doesn't need
>> to enable any backward compat handling as long as the Android (API) version
>> is equal or lower than the provided targetSdkVersion.
>>
>> Such compat handling could e.g. be w.r.t. App permissions, if there are
>> newer more granular one, or the default set got reduced it might break older
>> apps, so that is only enabled if the app signals that it supports it,
>> naturally with some time window to not allow uploading an app (update) to
>> avoid that this can be misused.
>>
>> The compileSdkVersion is the API the app is compiled against and thus
>> one can only actively use newer APIs if one increases this. Most of the time
>> one want's to have those two in sync, but it's fine if the targetSdkVersion
>> gets higher, it just cannot be lower than the compiled one.
>
> sorry to continue this, but there is something I don't really understand here
> (not that I want to say you're wrong, just wanting to understand)
>
> how can my 'target sdk version' be higher than my 'compiled sdk version' ?
>
> in that, how can i target sdks that are newer than the one i compile against?
> wouldn't that mean that the old sdk (e.g. 35 in our case) must have
> knowledge about the next version ?
Do not take the word "target" literally here, it should be interpreted as
"tested" and is for forward compat, as the article (and my prev. reply)
agrees upon.
>
> e.g i found an article[0] about those versions (not sure how good or representative it is)
>
> that explicitely says:
>
> ---
> If you made it through the bolded notes, you’ll notice a relationship between the three values:
>
> minSdkVersion <= targetSdkVersion <= compileSdkVersion
> ---
>
> which would mean that my target version can't be higher than my compile version...
That seems rather wrong, especially if one reads the explanation text
which gets it right. Cannot really make sense to be able to use newer
APIs thanks to a higher compileSdkVersion – which value is not recorded
in the resulting apk/appbundle – but then tell android that it's only
compatible with older ones.
The other direction, being compiled with an older SDK (API) really
doesn't mean that ones app runs perfectly fine on a newer android, thus it
can target the newer android without raising the compiled SDK version.
> that said, the app built successfully with these values, and I noticed no problem
> with either android 15 and 16 (in an emulator...)
There really shouldn't be any, the article is quite good but that
conclusion you quote is IMO where it got the summary wrong.
> 0:
> https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-03 14:56 ` Thomas Lamprecht
@ 2025-07-03 15:18 ` Tim Marx
2025-07-04 6:52 ` Shan Shaji
2025-07-04 8:53 ` Thomas Lamprecht
0 siblings, 2 replies; 13+ messages in thread
From: Tim Marx @ 2025-07-03 15:18 UTC (permalink / raw)
To: Proxmox VE development discussion, Thomas Lamprecht,
Dominik Csapak, Shan Shaji
I think you are misinterpreting that Thomas, I meant what I said before.
The post Dominik referenced is right here, it definitely says that you should not have a higher targetSdkVersion, that is due the the Gradle build process and how they determine runtime compatibility for release builds and debug builds.
https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
In the comments it is iterated again:
https://medium.com/@ianhlake/libraries-that-you-are-including-as-aars-or-remote-dependencies-from-maven-repositories-are-ca6cd7dd96ec
It does not make sense to me to have a higher target, you can't test that if you compile against a lower SDK.
> Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 03.07.2025 16:56 CEST geschrieben:
>
>
> Am 03.07.25 um 16:45 schrieb Dominik Csapak:
> > On 7/3/25 16:25, Thomas Lamprecht wrote:
> >> Am 03.07.25 um 16:03 schrieb Dominik Csapak:
> >>> LGTM, and built + tested fine here,
> >>> but maybe someone else also wants to take a look too... (@thomas?)
> >>>
> >>> Does it even make sense to set the targetSdkVersion higher than the compiled one?
> >>
> >> Yeah, that can be fine, the targetSdkVersion basically denotes what (API)
> >> version one tested the App against and signals Android that it doesn't need
> >> to enable any backward compat handling as long as the Android (API) version
> >> is equal or lower than the provided targetSdkVersion.
> >>
> >> Such compat handling could e.g. be w.r.t. App permissions, if there are
> >> newer more granular one, or the default set got reduced it might break older
> >> apps, so that is only enabled if the app signals that it supports it,
> >> naturally with some time window to not allow uploading an app (update) to
> >> avoid that this can be misused.
> >>
> >> The compileSdkVersion is the API the app is compiled against and thus
> >> one can only actively use newer APIs if one increases this. Most of the time
> >> one want's to have those two in sync, but it's fine if the targetSdkVersion
> >> gets higher, it just cannot be lower than the compiled one.
> >
> > sorry to continue this, but there is something I don't really understand here
> > (not that I want to say you're wrong, just wanting to understand)
> >
> > how can my 'target sdk version' be higher than my 'compiled sdk version' ?
> >
> > in that, how can i target sdks that are newer than the one i compile against?
> > wouldn't that mean that the old sdk (e.g. 35 in our case) must have
> > knowledge about the next version ?
>
> Do not take the word "target" literally here, it should be interpreted as
> "tested" and is for forward compat, as the article (and my prev. reply)
> agrees upon.
>
> >
> > e.g i found an article[0] about those versions (not sure how good or representative it is)
> >
> > that explicitely says:
> >
> > ---
> > If you made it through the bolded notes, you’ll notice a relationship between the three values:
> >
> > minSdkVersion <= targetSdkVersion <= compileSdkVersion
> > ---
> >
> > which would mean that my target version can't be higher than my compile version...
>
> That seems rather wrong, especially if one reads the explanation text
> which gets it right. Cannot really make sense to be able to use newer
> APIs thanks to a higher compileSdkVersion – which value is not recorded
> in the resulting apk/appbundle – but then tell android that it's only
> compatible with older ones.
>
> The other direction, being compiled with an older SDK (API) really
> doesn't mean that ones app runs perfectly fine on a newer android, thus it
> can target the newer android without raising the compiled SDK version.
>
> > that said, the app built successfully with these values, and I noticed no problem
> > with either android 15 and 16 (in an emulator...)
>
> There really shouldn't be any, the article is quite good but that
> conclusion you quote is IMO where it got the summary wrong.
>
>
> > 0:
> > https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
> >
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-03 15:18 ` Tim Marx
@ 2025-07-04 6:52 ` Shan Shaji
2025-07-04 8:53 ` Thomas Lamprecht
1 sibling, 0 replies; 13+ messages in thread
From: Shan Shaji @ 2025-07-04 6:52 UTC (permalink / raw)
To: Tim Marx, Proxmox VE development discussion, Thomas Lamprecht,
Dominik Csapak
Guys, I am sorry it's my mistake. The targetSdkVersion version
should be <= compileSdkVersion [0] version. Since the biometric_storage
plugin uses compileSdkVersion 35 i will update the
targetSdkVersion to 35 and will create another patch.
[0] - https://developer.android.com/build#android_sdk_settings
On Thu Jul 3, 2025 at 5:18 PM CEST, Tim Marx wrote:
> I think you are misinterpreting that Thomas, I meant what I said before.
>
> The post Dominik referenced is right here, it definitely says that you should not have a higher targetSdkVersion, that is due the the Gradle build process and how they determine runtime compatibility for release builds and debug builds.
> https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
>
> In the comments it is iterated again:
> https://medium.com/@ianhlake/libraries-that-you-are-including-as-aars-or-remote-dependencies-from-maven-repositories-are-ca6cd7dd96ec
>
> It does not make sense to me to have a higher target, you can't test that if you compile against a lower SDK.
>
> > Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 03.07.2025 16:56 CEST geschrieben:
> >
> >
> > Am 03.07.25 um 16:45 schrieb Dominik Csapak:
> > > On 7/3/25 16:25, Thomas Lamprecht wrote:
> > >> Am 03.07.25 um 16:03 schrieb Dominik Csapak:
> > >>> LGTM, and built + tested fine here,
> > >>> but maybe someone else also wants to take a look too... (@thomas?)
> > >>>
> > >>> Does it even make sense to set the targetSdkVersion higher than the compiled one?
> > >>
> > >> Yeah, that can be fine, the targetSdkVersion basically denotes what (API)
> > >> version one tested the App against and signals Android that it doesn't need
> > >> to enable any backward compat handling as long as the Android (API) version
> > >> is equal or lower than the provided targetSdkVersion.
> > >>
> > >> Such compat handling could e.g. be w.r.t. App permissions, if there are
> > >> newer more granular one, or the default set got reduced it might break older
> > >> apps, so that is only enabled if the app signals that it supports it,
> > >> naturally with some time window to not allow uploading an app (update) to
> > >> avoid that this can be misused.
> > >>
> > >> The compileSdkVersion is the API the app is compiled against and thus
> > >> one can only actively use newer APIs if one increases this. Most of the time
> > >> one want's to have those two in sync, but it's fine if the targetSdkVersion
> > >> gets higher, it just cannot be lower than the compiled one.
> > >
> > > sorry to continue this, but there is something I don't really understand here
> > > (not that I want to say you're wrong, just wanting to understand)
> > >
> > > how can my 'target sdk version' be higher than my 'compiled sdk version' ?
> > >
> > > in that, how can i target sdks that are newer than the one i compile against?
> > > wouldn't that mean that the old sdk (e.g. 35 in our case) must have
> > > knowledge about the next version ?
> >
> > Do not take the word "target" literally here, it should be interpreted as
> > "tested" and is for forward compat, as the article (and my prev. reply)
> > agrees upon.
> >
> > >
> > > e.g i found an article[0] about those versions (not sure how good or representative it is)
> > >
> > > that explicitely says:
> > >
> > > ---
> > > If you made it through the bolded notes, you’ll notice a relationship between the three values:
> > >
> > > minSdkVersion <= targetSdkVersion <= compileSdkVersion
> > > ---
> > >
> > > which would mean that my target version can't be higher than my compile version...
> >
> > That seems rather wrong, especially if one reads the explanation text
> > which gets it right. Cannot really make sense to be able to use newer
> > APIs thanks to a higher compileSdkVersion – which value is not recorded
> > in the resulting apk/appbundle – but then tell android that it's only
> > compatible with older ones.
> >
> > The other direction, being compiled with an older SDK (API) really
> > doesn't mean that ones app runs perfectly fine on a newer android, thus it
> > can target the newer android without raising the compiled SDK version.
> >
> > > that said, the app built successfully with these values, and I noticed no problem
> > > with either android 15 and 16 (in an emulator...)
> >
> > There really shouldn't be any, the article is quite good but that
> > conclusion you quote is IMO where it got the summary wrong.
> >
> >
> > > 0:
> > > https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
> > >
> >
> >
> >
> > _______________________________________________
> > pve-devel mailing list
> > pve-devel@lists.proxmox.com
> > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-03 15:18 ` Tim Marx
2025-07-04 6:52 ` Shan Shaji
@ 2025-07-04 8:53 ` Thomas Lamprecht
2025-07-04 11:15 ` Shan Shaji
1 sibling, 1 reply; 13+ messages in thread
From: Thomas Lamprecht @ 2025-07-04 8:53 UTC (permalink / raw)
To: Tim Marx, Proxmox VE development discussion, Dominik Csapak, Shan Shaji
Am 03.07.25 um 17:18 schrieb Tim Marx:
> I think you are misinterpreting that Thomas, I meant what I said before.
>
> The post Dominik referenced is right here, it definitely says that you should not have a higher targetSdkVersion, that is due the the Gradle build process and how they determine runtime compatibility for release builds and debug builds.
> https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
>
> In the comments it is iterated again:
> https://medium.com/@ianhlake/libraries-that-you-are-including-as-aars-or-remote-dependencies-from-maven-repositories-are-ca6cd7dd96ec
>
> It does not make sense to me to have a higher target, you can't test that if you compile against a lower SDK.
Yeah, I rechecked I was indeed misinterpreting this and found some confirmation
bias on (confused) answers online like stack overflow, thanks to you and
Dominik for clearing this up!
One thing that annoys me a bit is though that per the Link from Shan it
really states very explicitly in the official docs:
> The value of `targetSdk` must be less than or equal to that of `compileSdk`.
So breaking this should really result in a build error...
But anyway, @Shan, let's upgrade biometrics storage instead, maybe there's a new
version already, or alternatively ugprade it ourselves (and also sent that patch
upstream). FWIW, we had already a downstream version using a path dependency of
that library in the past for an important bug fix, so doing this would be the
first time.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-04 8:53 ` Thomas Lamprecht
@ 2025-07-04 11:15 ` Shan Shaji
2025-07-07 9:51 ` Shan Shaji
0 siblings, 1 reply; 13+ messages in thread
From: Shan Shaji @ 2025-07-04 11:15 UTC (permalink / raw)
To: Thomas Lamprecht, Tim Marx, Proxmox VE development discussion,
Dominik Csapak
There is no new version available. We are already using the new version.
Did a little more research and may be we don't need to upgrade the
plugin. When i checked running the app on Android 16 (Emulator -
mocking the finger print feature from settings) by upgrading the
`targetSdkVersion` and `compileSdkVersion` to 36 it worked fine.
I was able to compile build and run the app successfully,
didn't got any compilation or depraction warnings. likely because the
plugin doesn't rely on any APIs that were deprecated or removed in
API level 36 but were still present in 35. Since the app is compiled
with API level 36, It includes APIs from previousl levels, including
35. Given that most changes in newer APIs are additive [0],
I think we can continue using the API level 35 in the plugin.
[0] - https://developer.android.com/guide/topics/manifest/uses-sdk-element#fc
On Fri Jul 4, 2025 at 10:53 AM CEST, Thomas Lamprecht wrote:
> Am 03.07.25 um 17:18 schrieb Tim Marx:
> > I think you are misinterpreting that Thomas, I meant what I said before.
> >
> > The post Dominik referenced is right here, it definitely says that you should not have a higher targetSdkVersion, that is due the the Gradle build process and how they determine runtime compatibility for release builds and debug builds.
> > https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
> >
> > In the comments it is iterated again:
> > https://medium.com/@ianhlake/libraries-that-you-are-including-as-aars-or-remote-dependencies-from-maven-repositories-are-ca6cd7dd96ec
> >
> > It does not make sense to me to have a higher target, you can't test that if you compile against a lower SDK.
>
>
> Yeah, I rechecked I was indeed misinterpreting this and found some confirmation
> bias on (confused) answers online like stack overflow, thanks to you and
> Dominik for clearing this up!
>
> One thing that annoys me a bit is though that per the Link from Shan it
> really states very explicitly in the official docs:
>
> > The value of `targetSdk` must be less than or equal to that of `compileSdk`.
>
> So breaking this should really result in a build error...
>
> But anyway, @Shan, let's upgrade biometrics storage instead, maybe there's a new
> version already, or alternatively ugprade it ourselves (and also sent that patch
> upstream). FWIW, we had already a downstream version using a path dependency of
> that library in the past for an important bug fix, so doing this would be the
> first time.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36
2025-07-04 11:15 ` Shan Shaji
@ 2025-07-07 9:51 ` Shan Shaji
0 siblings, 0 replies; 13+ messages in thread
From: Shan Shaji @ 2025-07-07 9:51 UTC (permalink / raw)
To: Proxmox VE development discussion, Thomas Lamprecht, Tim Marx,
Dominik Csapak
Created a new patch [0] by updating the compileSdkVersion to 36. Now
both the `compileSdkVersion` and `targetSdkVersion` are 36.
- [0] https://lore.proxmox.com/pve-devel/20250707094800.68832-1-s.shaji@proxmox.com/T/#u
On Fri Jul 4, 2025 at 1:15 PM CEST, Shan Shaji wrote:
> There is no new version available. We are already using the new version.
> Did a little more research and may be we don't need to upgrade the
> plugin. When i checked running the app on Android 16 (Emulator -
> mocking the finger print feature from settings) by upgrading the
> `targetSdkVersion` and `compileSdkVersion` to 36 it worked fine.
>
> I was able to compile build and run the app successfully,
> didn't got any compilation or depraction warnings. likely because the
> plugin doesn't rely on any APIs that were deprecated or removed in
> API level 36 but were still present in 35. Since the app is compiled
> with API level 36, It includes APIs from previousl levels, including
> 35. Given that most changes in newer APIs are additive [0],
> I think we can continue using the API level 35 in the plugin.
>
> [0] - https://developer.android.com/guide/topics/manifest/uses-sdk-element#fc
>
>
> On Fri Jul 4, 2025 at 10:53 AM CEST, Thomas Lamprecht wrote:
> > Am 03.07.25 um 17:18 schrieb Tim Marx:
> > > I think you are misinterpreting that Thomas, I meant what I said before.
> > >
> > > The post Dominik referenced is right here, it definitely says that you should not have a higher targetSdkVersion, that is due the the Gradle build process and how they determine runtime compatibility for release builds and debug builds.
> > > https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
> > >
> > > In the comments it is iterated again:
> > > https://medium.com/@ianhlake/libraries-that-you-are-including-as-aars-or-remote-dependencies-from-maven-repositories-are-ca6cd7dd96ec
> > >
> > > It does not make sense to me to have a higher target, you can't test that if you compile against a lower SDK.
> >
> >
> > Yeah, I rechecked I was indeed misinterpreting this and found some confirmation
> > bias on (confused) answers online like stack overflow, thanks to you and
> > Dominik for clearing this up!
> >
> > One thing that annoys me a bit is though that per the Link from Shan it
> > really states very explicitly in the official docs:
> >
> > > The value of `targetSdk` must be less than or equal to that of `compileSdk`.
> >
> > So breaking this should really result in a build error...
> >
> > But anyway, @Shan, let's upgrade biometrics storage instead, maybe there's a new
> > version already, or alternatively ugprade it ourselves (and also sent that patch
> > upstream). FWIW, we had already a downstream version using a path dependency of
> > that library in the past for an important bug fix, so doing this would be the
> > first time.
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2025-07-07 9:51 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-02 9:10 [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36 Shan Shaji
2025-07-03 14:03 ` Dominik Csapak
2025-07-03 14:20 ` Tim Marx
2025-07-03 14:28 ` Thomas Lamprecht
2025-07-03 14:25 ` Thomas Lamprecht
2025-07-03 14:45 ` Dominik Csapak
2025-07-03 14:56 ` Thomas Lamprecht
2025-07-03 15:18 ` Tim Marx
2025-07-04 6:52 ` Shan Shaji
2025-07-04 8:53 ` Thomas Lamprecht
2025-07-04 11:15 ` Shan Shaji
2025-07-07 9:51 ` Shan Shaji
2025-07-03 14:36 ` [pve-devel] applied: " Thomas Lamprecht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal