Android 11 kommer att introducera ett utvecklaralternativ "App-kompatibilitet" för att testa plattformsändringar

Varje år på Google I/O lyfter Google fram några av de mest spännande förändringarna som kommer till nästa version av Android. Medan de flesta användare bedömer Android-versioner efter de visuella förändringarna som påverkar deras upplevelse, kommer varje Android-uppdatering också med massor av ändringar i API: er och plattformsbeteende. Dessa förändringar är viktiga för apputvecklare att ta del av och förbereda sina appar för, eftersom de i grunden kan förändra hur deras appar kan konsumeras av slutanvändare. Med nästa version av Android, Android 11, kommer Google att göra det enklare för utvecklare att testa och förbereda sina appar för kommande ändringar med en ny "App-kompatibilitet"-inställning i Utvecklaralternativ.

Varje gång Google släpper en ny Android-version, apputvecklare som är intresserade av att aktivt underhålla deras applikationer behöver läsa på om de nya ändringarna och den dokumentation som följer med för dessa ändringar. De kan sedan bestämma sig för att uppdatera sin app för att lägga till dessa nya API-funktioner om de vill eller migrera sin användning av befintliga API: er till nyare API: er, en sökväg som kanske är valfri eller inte. Apputvecklare behöver inte uppdatera mål-API för sina appar omedelbart, men de måste göra det så småningom för att uppfylla

ändrade mål-API-krav för Google Play Butik. Efter detta måste utvecklare också faktiskt testa sin app på den nya Android-versionen, och detta kan göras på en emulerad enhet, en molnvärd enhet eller en lokal enhet. Testning är en del av utvecklingsrutinen, men testning blir ännu viktigare när det är stora förändringar inblandade.

Vidare, när Google vill införa stora plattformsbeteendeförändringar implementerar de inte omedelbart förändringen i den nya versionen av Android. Detta för att skydda användare från att många av deras appar går sönder och förlorar funktionalitet, och det ger också utvecklare mer tid att uppdatera sina appar. Till exempel, i Android 7 Nougat, beslutade Google att begränsa vissa implicita sändningar för att spara batteritid. Med Android 8 Oreo, Google helt begränsade appar från att registrera implicita sändningsmottagare. Men innan Android 8 Oreo släpptes ville Google att utvecklarna skulle förbereda sig för ett scenario där deras appar inte längre skulle kunna registrera implicita sändningsmottagare. Och för detta kunde utvecklare använd ett ADB-kommando i Android 7 Nougat för att simulera ett tillstånd där implicita sändningar inte är tillgängliga:

adb shell cmd appops set RUN_IN_BACKGROUND ignore

ADB-kommandon som det ovan är ett exempel på hur Google tillåter apputvecklare att testa hur deras appar skulle bete sig under beteendeförändringar i Android-plattformen.

Ett annat färskt exempel är hur i Android Q Beta 2, Google bad utvecklare att testa Scoped Storage på sina appar genom att köra detta ADB-kommando:

adb shell cmd appops set your-package-name android: legacy_storage default && \

Som apputvecklare kan man anta att du är bekväm med ADB-kommandon och inte är särskilt motvillig att använda dem för att testa dessa plattformsförändringar. Men det finns alltid utrymme för förbättringar, och Google gör denna testprocess enklare genom att introducera ett enkelt användargränssnitt för att kontrollera dessa ändringar.

Med det nya PlatformCompat-projekt, behöver utvecklare inte längre köra ADB-kommandon för varje ny plattformsbeteendeförändring. Med Android 11 kommer Android att ha en ny undermeny inom utvecklaralternativ för att snabbt växla nya plattformsbeteendeförändringar per app, utan att behöva skicka några ADB-skalkommandon. Det kommer att finnas olika avsnitt för varje mål-API-nivå -- till exempel kommer API-nivå > 29 att ha sin egen uppsättning beteendeförändringar som kan växlas, medan API-nivå > 30 kommer att ha sin egen uppsättning av ändringar.

I skärmdumpen ovan som visar avsnittet Appkompatibilitet (från en källbyggd AOSP som körs på en emulator), "Standard Aktiverade ändringar" innehåller Android 11 API-ändringar som kommer att aktiveras som standard på alla appar oavsett deras mål SDK. Avsnittet "aktiverat för targetSDKversion > 29" är Android 11 API-ändringar som endast är aktiverade för appar som är inriktade på Android 11/API nivå 30.

Även om denna förändring inte direkt kommer att reta slutanvändare, gör den jobbet för apputvecklare enklare, och det är alltid bra.

---

Tack vare XDA Recognized Developer luca020400 för tipset och för att tillhandahålla den bifogade skärmdumpen.

Ytterligare täckning på Android 11:

• Android 11 kan äntligen ta bort Androids filstorleksgräns på 4 GB för videoinspelningar
• Schemaläggning för mörkt läge kan komma i Android 11
• Flygplansläge kan äntligen sluta stänga av Bluetooth-ljud, från och med Android 11 R
• Google fasar ut Androids AsyncTask API i Android 11
• Google kommer att få filhanterare att skicka in ett formulär för att få bred åtkomst till fillagring i Android 11
• Android 11 kan äntligen komma med en ordentlig, inbyggd trådlös ADB-implementering