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