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