Android 11 wordt geleverd met een nieuwe instelling 'App-compatibiliteit' in de ontwikkelaarsoptie, waardoor het voor app-ontwikkelaars gemakkelijker wordt om wijzigingen in het platformgedrag te testen.
Elk jaar belicht Google tijdens Google I/O enkele van de meest opwindende veranderingen die naar de volgende versie van Android komen. Hoewel de meeste gebruikers Android-versies beoordelen op basis van de visuele veranderingen die hun ervaring beïnvloeden, bevat elke Android-update ook een heleboel wijzigingen in API's En platformgedrag. Deze veranderingen zijn belangrijk voor app-ontwikkelaars om kennis van te nemen en hun apps op voor te bereiden, omdat ze de manier waarop hun apps door eindgebruikers kunnen worden geconsumeerd fundamenteel kunnen veranderen. Met de volgende versie van Android, Android 11, zal Google het voor ontwikkelaars gemakkelijker maken om hun apps te testen en voor te bereiden op aanstaande wijzigingen met een nieuwe instelling ‘App-compatibiliteit’ in Ontwikkelaarsopties.
Telkens wanneer Google een nieuwe Android-versie uitbrengt, willen app-ontwikkelaars deze actief onderhouden hun applicaties moeten de nieuwe wijzigingen en de bijbehorende documentatie lezen veranderingen. Ze kunnen vervolgens besluiten hun app bij te werken om deze nieuwe API-functies toe te voegen als ze dat willen, of hun gebruik van bestaande API's naar nieuwere API's te migreren, een pad dat al dan niet optioneel is. App-ontwikkelaars hoeven de doel-API van hun apps niet onmiddellijk bij te werken, maar ze moeten dit uiteindelijk wel doen om aan de vereisten te voldoen veranderende doel-API-vereisten van de Google Play Store. Hierna moeten ontwikkelaars hun app ook daadwerkelijk testen op de nieuwe Android-versie, en dit kan worden gedaan op een geëmuleerd apparaat, een in de cloud gehost apparaat of een lokaal apparaat. Testen is onderdeel van de ontwikkelingsroutine, maar testen wordt nog belangrijker als er sprake is van grote veranderingen.
Bovendien, wanneer Google grote veranderingen in het platformgedrag wil doorvoeren, implementeren ze de verandering niet onmiddellijk in de nieuwe Android-versie. Dit is om gebruikers te beschermen tegen het feit dat veel van hun apps kapot gaan en functionaliteit verliezen, en het geeft ontwikkelaars ook meer tijd om hun apps bij te werken. In Android 7 Nougat besloot Google dat bijvoorbeeld te doen bepaalde impliciete uitzendingen beperken om de levensduur van de batterij te verlengen. Met Android 8 Oreo, Google volledig verboden dat apps impliciete uitzendingsontvangers registreren. Maar voordat Android 8 Oreo werd uitgebracht, wilde Google dat ontwikkelaars zich voorbereidden op een scenario waarin hun apps niet langer impliciete uitzendingsontvangers zouden kunnen registreren. En hiervoor zouden ontwikkelaars dat kunnen doen gebruik een ADB-opdracht in Android 7 Nougat om een situatie te simuleren waarin impliciete uitzendingen niet beschikbaar zijn:
adb shell cmd appops set RUN_IN_BACKGROUND ignoreADB-opdrachten zoals hierboven zijn een voorbeeld van hoe Google app-ontwikkelaars toestaat te testen hoe hun apps zich zouden gedragen onder gedragsveranderingen op het Android-platform.
Een ander recent voorbeeld is hoe in Android Q Beta 2 Google vroeg ontwikkelaars om Scoped Storage te testen in hun apps door deze ADB-opdracht uit te voeren:
adb shell cmd appops set your-package-name android: legacy_storage default && \Als app-ontwikkelaar kun je ervan uitgaan dat je vertrouwd bent met ADB-opdrachten en er niet bepaald afkerig van bent om deze te gebruiken om deze platformwijzigingen uit te testen. Maar er is altijd ruimte voor verbetering, en Google maakt dit testproces eenvoudiger door een eenvoudige gebruikersinterface te introduceren om deze wijzigingen te beheren.
Met de nieuwe PlatformCompat-projecthoeven ontwikkelaars niet langer ADB-opdrachten uit te voeren voor elke nieuwe platformgedragsverandering. Met Android 11 krijgt Android een nieuw submenu binnen Developer Options om snel nieuwe platformgedragsveranderingen per app in te schakelen, zonder dat er ADB-shell-opdrachten hoeven te worden verzonden. Er zullen verschillende secties zijn voor elk doel-API-niveau, bijvoorbeeld voor API-niveau > 29 zijn eigen reeks gedragsveranderingen die kunnen worden omgeschakeld, terwijl API-niveau> 30 zijn eigen reeks zal hebben veranderingen.
In de bovenstaande schermafbeelding waarin het gedeelte App-compatibiliteit wordt getoond (van een door de bron gebouwde AOSP die op een emulator draait), wordt de optie 'Standaard Ingeschakelde wijzigingen bevat de Android 11 API-wijzigingen die standaard worden ingeschakeld voor alle apps, ongeacht hun doel SDK. De sectie 'ingeschakeld voor targetSDKversie > 29' bevat wijzigingen in de Android 11 API die alleen zijn ingeschakeld voor apps die zich richten op Android 11/API-niveau 30.
Hoewel deze specifieke verandering eindgebruikers niet direct enthousiast zal maken, maakt het het werk van app-ontwikkelaars wel gemakkelijker, en dat is altijd een goede zaak.
Met dank aan XDA erkende ontwikkelaar luca020400 voor de tip en voor het aanleveren van de bijgevoegde screenshot.
Verdere dekking op Android 11:
- Android 11 kan eindelijk de Android-bestandsgroottelimiet van 4 GB voor video-opnamen verwijderen
- Planning in de donkere modus zou beschikbaar kunnen zijn in Android 11
- Vliegtuigmodus kan eindelijk stoppen met het afsluiten van Bluetooth-audio, te beginnen met Android 11 R
- Google beëindigt de AsyncTask API van Android in Android 11
- Google zal ontwikkelaars van bestandsbeheer een formulier laten indienen om brede toegang tot bestandsopslag te krijgen in Android 11
- Android 11 kan eindelijk een goede, native Wireless ADB-implementatie brengen