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
