Android 11 vil introducere en "App-kompatibilitet" udviklermulighed for at hjælpe med at teste platformsændringer

click fraud protection

Android 11 kommer med en ny "App-kompatibilitet"-indstilling i Developer Option, hvilket gør det nemmere for app-udviklere at teste ændringer af platformens adfærd.

Hvert år på Google I/O fremhæver Google nogle af de mest spændende ændringer, der kommer til den næste version af Android. Mens de fleste brugere bedømmer Android-versioner ud fra de visuelle ændringer, der påvirker deres oplevelse, kommer hver Android-opdatering også med et væld af ændringer til API'er og platforms adfærd. Disse ændringer er vigtige for app-udviklere at notere sig og forberede deres apps til, da de fundamentalt kan ændre måden, hvorpå deres apps kan forbruges af slutbrugere. Med den næste version af Android, Android 11, vil Google gøre det nemmere for udviklere at teste og forberede deres apps til kommende ændringer med en ny "App-kompatibilitet"-indstilling i Udviklerindstillinger.

Hver gang Google udgiver en ny Android-version, app-udviklere, der er interesseret i aktivt at vedligeholde deres ansøgninger skal læse op på de nye ændringer og den dokumentation, der følger med for disse ændringer. De kan derefter beslutte at opdatere deres app for at tilføje disse nye API-funktioner, hvis de ønsker at eller migrere deres brug af eksisterende API'er til nyere API'er, en sti, der måske eller måske ikke er valgfri. App-udviklere behøver ikke at opdatere mål-API'en for deres apps med det samme, men de skal gøre det til sidst for at opfylde

skiftende mål-API-krav i Google Play Butik. Herefter skal udviklere også faktisk teste deres app på den nye Android-version, og dette kan gøres på en emuleret enhed, en cloud-hostet enhed eller en lokal enhed. Test er en del af udviklingsrutinen, men test bliver endnu vigtigere, når der er store ændringer involveret.

Yderligere, når Google ønsker at introducere større platformsadfærdsændringer, implementerer de ikke straks ændringen i den nye Android-version. Dette er for at beskytte brugerne mod at få mange af deres apps i stykker og miste funktionalitet, og det giver også udviklere mere tid til at opdatere deres apps. For eksempel i Android 7 Nougat besluttede Google at begrænse nogle implicitte udsendelser for at spare batterilevetid. Med Android 8 Oreo, Google fuldstændigt begrænsede apps fra at registrere implicitte udsendelsesmodtagere. Men før Android 8 Oreo blev frigivet, ønskede Google, at udviklere skulle forberede sig på et scenarie, hvor deres apps ikke længere ville være i stand til at registrere implicitte broadcast-modtagere. Og for dette kunne udviklere brug en ADB-kommando i Android 7 Nougat til at simulere en tilstand, hvor implicitte udsendelser ikke er tilgængelige:

adb shell cmd appops set RUN_IN_BACKGROUND ignore

ADB-kommandoer som den ovenfor er et eksempel på, hvordan Google tillader app-udviklere at teste, hvordan deres apps ville opføre sig under Android-platforms adfærdsændringer.

Et andet nyligt eksempel er, hvordan i Android Q Beta 2, Google bad udviklere om at teste Scoped Storage på deres apps ved at køre denne ADB-kommando:

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

Som app-udvikler kan man formode, at du er fortrolig med ADB-kommandoer og ikke er særlig uvillig til at bruge dem til at teste disse platformsændringer. Men der er altid plads til forbedringer, og Google gør denne testproces lettere ved at introducere en simpel brugergrænseflade til at kontrollere disse ændringer.

Med det nye PlatformCompat projekt, behøver udviklere ikke længere at køre ADB-kommandoer for hver ny platforms adfærdsændring. Med Android 11 vil Android have en ny undermenu i Udviklerindstillinger for hurtigt at skifte nye platformsadfærdsændringer pr. app, uden at skulle sende nogen ADB-shell-kommandoer. Der vil være forskellige sektioner for hvert mål-API-niveau -- for eksempel vil API-niveau > 29 have sit eget sæt adfærdsændringer, der kan skiftes, mens API-niveau > 30 vil have sit eget sæt af ændringer.

I skærmbilledet ovenfor, der viser afsnittet om appkompatibilitet (fra en kildebygget AOSP, der kører på en emulator), vises "Standard" Aktiverede ændringer" sektionen inkluderer Android 11 API-ændringer, der vil blive aktiveret som standard på alle apps uanset deres mål SDK. Afsnittet "aktiveret for targetSDKversion > 29" er Android 11 API-ændringer, der kun er aktiveret for apps, der er målrettet mod Android 11/API niveau 30.

Selvom denne særlige ændring ikke direkte vil begejstre slutbrugere, gør den jobbet for appudviklere lettere, og det er altid en god ting.


Tak til XDA Recognized Developer luca020400 for tippet og for at give det vedhæftede skærmbillede.

Yderligere dækning på Android 11:

  • Android 11 kan endelig fjerne Androids 4 GB filstørrelsesgrænse for videooptagelser
  • Mørk tilstandsplanlægning kan komme i Android 11
  • Flytilstand stopper muligvis endelig med at lukke Bluetooth-lyden ned, startende med Android 11 R
  • Google udfaser Androids AsyncTask API i Android 11
  • Google vil få filhåndteringsudviklere til at indsende en formular for at få bred fillageradgang i Android 11
  • Android 11 kan endelig bringe en ordentlig, indbygget trådløs ADB-implementering