From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id C02AB1FF164 for ; Fri, 4 Jul 2025 13:15:47 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6012336244; Fri, 4 Jul 2025 13:16:27 +0200 (CEST) Mime-Version: 1.0 Date: Fri, 04 Jul 2025 13:15:53 +0200 Message-Id: From: "Shan Shaji" To: "Thomas Lamprecht" , "Tim Marx" , "Proxmox VE development discussion" , "Dominik Csapak" X-Mailer: aerc 0.14.0 References: <20250702091056.60732-1-s.shaji@proxmox.com> <20499aba-f114-4a55-92bd-e43eca44cab7@proxmox.com> <9e82aa80-6e7e-406e-9ea0-92ec3dc7c79e@proxmox.com> <21cdddbf-5bfa-4b3b-885c-79afbe54603c@proxmox.com> <1893456957.1437.1751555908572@webmail.proxmox.com> <4ad500da-d5bc-40d8-9d76-d6b71d4b7a5d@proxmox.com> In-Reply-To: <4ad500da-d5bc-40d8-9d76-d6b71d4b7a5d@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.016 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_NUMSUBJECT 0.5 Subject ends in numbers excluding current years SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_SBL_A 0.1 Contains URL's A record listed in the Spamhaus SBL blocklist [142.250.185.174] Subject: Re: [pve-devel] [PATCH pve_flutter_frontend v1] chore: update `compileSdkVersion` to 35 and `targetSdkVersion` to 36 X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel