[pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Shan Shaji]

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[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?

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[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.

> 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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Thomas Lamprecht]

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Thomas Lamprecht]

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[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 ?

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Thomas Lamprecht]

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[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.

> 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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Shan Shaji]

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Thomas Lamprecht]

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Shan Shaji]

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

Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Shan Shaji]

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

[pve-devel] applied: [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36

[Thomas Lamprecht]

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