Android 11 vil introdusere et "App-kompatibilitet"-utvikleralternativ for å teste plattformendringer

Hvert år på Google I/O fremhever Google noen av de mest spennende endringene som kommer til neste versjon av Android. Mens de fleste brukere bedømmer Android-versjoner etter de visuelle endringene som påvirker opplevelsen deres, kommer hver Android-oppdatering også med massevis av endringer i APIer og plattformadferd. Disse endringene er viktige for apputviklere å legge merke til og forberede appene sine på, siden de fundamentalt kan endre måtene appene deres kan konsumeres på av sluttbrukere. Med neste versjon av Android, Android 11, vil Google gjøre det enklere for utviklere å teste og forberede appene sine for kommende endringer med en ny "App-kompatibilitet"-innstilling i Utvikleralternativer.

Hver gang Google slipper en ny Android-versjon, apputviklere som er interessert i å aktivt vedlikeholde søknadene deres må lese seg opp om de nye endringene og dokumentasjonen som følger med for disse Endringer. De kan da bestemme seg for å oppdatere appen sin for å legge til disse nye API-funksjonene hvis de ønsker å eller migrere bruken av eksisterende APIer til nyere APIer, en bane som kanskje er valgfri eller ikke. Apputviklere trenger ikke å oppdatere mål-API-en til appene sine umiddelbart, men de må gjøre det til slutt for å oppfylle

skiftende mål-API-krav i Google Play-butikken. Etter dette må utviklere også faktisk teste appen sin på den nye Android-versjonen, og dette kan gjøres på en emulert enhet, en sky-vertsenhet eller en lokal enhet. Testing er en del av utviklingsrutinen, men testing blir enda viktigere når det er store endringer involvert.

Videre, når Google ønsker å introdusere store plattformadferdsendringer, implementerer de ikke umiddelbart endringen i den nye Android-versjonsutgivelsen. Dette er for å beskytte brukere mot at mange av appene deres går i stykker og mister funksjonalitet, og det gir også utviklere mer tid til å oppdatere appene sine. For eksempel, i Android 7 Nougat bestemte Google seg for å begrense noen implisitte sendinger for å spare batterilevetid. Med Android 8 Oreo, Google fullstendig begrenset apper fra å registrere implisitte kringkastingsmottakere. Men før Android 8 Oreo ble utgitt, ønsket Google at utviklerne skulle forberede seg på et scenario der appene deres ikke lenger ville kunne registrere implisitte kringkastingsmottakere. Og for dette kunne utviklere bruk en ADB-kommando i Android 7 Nougat for å simulere en tilstand der implisitte sendinger ikke er tilgjengelige:

adb shell cmd appops set RUN_IN_BACKGROUND ignore

ADB-kommandoer som den ovenfor er et eksempel på hvordan Google lar apputviklere teste hvordan appene deres ville oppføre seg under atferdsendringer i Android-plattformen.

Et annet nylig eksempel er hvordan i Android Q Beta 2, Google ba utviklere om å teste Scoped Storage på appene deres ved å kjøre denne ADB-kommandoen:

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

Som apputvikler kan man anta at du er komfortabel med ADB-kommandoer og ikke er spesielt uvillig til å bruke dem til å teste ut disse plattformendringene. Men det er alltid rom for forbedringer, og Google gjør denne testprosessen enklere ved å introdusere et enkelt brukergrensesnitt for å kontrollere disse endringene.

Med den nye PlatformCompat-prosjekt, trenger ikke utviklere lenger å kjøre ADB-kommandoer for hver ny plattformadferdsendring. Med Android 11 vil Android ha en ny undermeny i Utvikleralternativer for raskt å bytte nye plattformadferdsendringer per app, uten å måtte sende noen ADB-skallkommandoer. Det vil være forskjellige seksjoner for hvert mål-API-nivå -- for eksempel vil API-nivå > 29 ha sitt eget sett med atferdsendringer som kan veksles, mens API-nivå > 30 vil ha sitt eget sett med Endringer.

I skjermbildet ovenfor som viser appkompatibilitetsdelen (fra en kildebygd AOSP som kjører på en emulator), "Standard Aktiverte endringer"-delen inkluderer Android 11 API-endringer som vil være aktivert som standard på alle apper uavhengig av deres mål SDK. Delen «aktivert for targetSDKversion > 29» er Android 11 API-endringer som bare er aktivert for apper som er målrettet mot Android 11/API nivå 30.

Selv om denne endringen ikke direkte vil begeistre sluttbrukere, gjør den jobben til apputviklere enklere, og det er alltid en god ting.

---

Takk til XDA Recognized Developer luca020400 for tipset og for å gi det vedlagte skjermbildet.

Ytterligere dekning på Android 11:

• Android 11 kan endelig fjerne Androids filstørrelsesgrense på 4 GB for videoopptak
• Mørk modus-planlegging kan komme i Android 11
• Flymodus kan endelig slutte å slå av Bluetooth-lyd, fra og med Android 11 R
• Google avvikler Androids AsyncTask API i Android 11
• Google vil få filbehandlerutviklere til å sende inn et skjema for å få bred fillagringstilgang i Android 11
• Android 11 kan endelig bringe en skikkelig, native Wireless ADB-implementering