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.lampre...@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
