[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 at 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 at lists.proxmox.com
> > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel