Android 11 va veni cu o nouă setare „Compatibilitate aplicație” în Opțiunea pentru dezvoltatori, facilitând pentru dezvoltatorii de aplicații să testeze modificările comportamentului platformei.
În fiecare an, la Google I/O, Google evidențiază unele dintre cele mai interesante schimbări care vin la următoarea versiune de Android. În timp ce majoritatea utilizatorilor judecă versiunile Android după modificările vizuale care le afectează experiența, fiecare actualizare Android vine și cu o mulțime de modificări ale API-urilor și comportamentul platformei. Aceste modificări sunt importante pentru care dezvoltatorii de aplicații să ia notă și să își pregătească aplicațiile, deoarece pot modifica în mod fundamental modurile în care aplicațiile lor pot fi consumate de utilizatorii finali. Cu următoarea versiune de Android, Android 11, Google va face mai ușor pentru dezvoltatori să testeze și să își pregătească aplicațiile pentru modificările viitoare cu o nouă setare „Compatibilitate aplicație” în Opțiuni pentru dezvoltatori.
De fiecare dată când Google lansează o nouă versiune de Android, dezvoltatorii de aplicații care sunt interesați să întrețină în mod activ aplicațiile lor trebuie să citească noile modificări și documentația care vine împreună pentru acestea schimbări. Ei pot decide apoi să-și actualizeze aplicația pentru a adăuga aceste noi funcții API dacă doresc sau să migreze utilizarea API-urilor existente la API-uri mai noi, o cale care poate fi sau nu opțională. Dezvoltatorii de aplicații nu trebuie să actualizeze imediat API-ul țintă al aplicațiilor lor, dar trebuie să o facă în cele din urmă pentru a îndeplini schimbarea cerințelor API-țintă ale Magazinului Google Play. După aceasta, dezvoltatorii trebuie, de asemenea, să-și testeze aplicația pe noua versiune Android, iar acest lucru se poate face pe un dispozitiv emulat, un dispozitiv găzduit în cloud sau un dispozitiv local. Testarea face parte din rutina de dezvoltare, dar testarea devine și mai importantă atunci când sunt implicate schimbări majore.
În plus, atunci când Google dorește să introducă schimbări majore în comportamentul platformei, nu implementează imediat schimbarea în noua versiune de Android. Acest lucru este pentru a proteja utilizatorii împotriva ca multe dintre aplicațiile lor să se rupă și să-și piardă funcționalitatea și, de asemenea, oferă dezvoltatorilor mai mult timp pentru a-și actualiza aplicațiile. De exemplu, în Android 7 Nougat, Google a decis să o facă limitarea unor emisiuni implicite pentru a economisi durata de viață a bateriei. Cu Android 8 Oreo, Google a restricționat complet aplicațiile de la înregistrarea receptoarelor de transmisie implicite. Dar înainte de lansarea Android 8 Oreo, Google dorea ca dezvoltatorii să se pregătească pentru un scenariu în care aplicațiile lor nu ar mai putea să înregistreze receptoare implicite de transmisie. Și pentru asta, dezvoltatorii ar putea utilizați o comandă ADB în Android 7 Nougat pentru a simula o condiție în care transmisiile implicite nu sunt disponibile:
adb shell cmd appops set RUN_IN_BACKGROUND ignoreComenzile ADB, cum ar fi cea de mai sus, sunt un exemplu al modului în care Google le permite dezvoltatorilor de aplicații să testeze modul în care aplicațiile lor s-ar comporta în cazul schimbărilor de comportament ale platformei Android.
Un alt exemplu recent este modul în care în Android Q Beta 2, Google le-a cerut dezvoltatorilor să testeze Scoped Storage în aplicațiile lor, rulând această comandă ADB:
adb shell cmd appops set your-package-name android: legacy_storage default && \În calitate de dezvoltator de aplicații, se poate presupune că vă simțiți confortabil cu comenzile ADB și că nu sunteți deosebit de contrariat să le folosiți pentru a testa aceste modificări ale platformei. Dar există întotdeauna loc de îmbunătățire, iar Google ușurează acest proces de testare prin introducerea unei interfețe de utilizare simplă pentru a controla aceste modificări.
Cu noul Proiect PlatformCompat, dezvoltatorii nu mai trebuie să ruleze comenzi ADB pentru fiecare schimbare de comportament nouă a platformei. Cu Android 11, Android va avea un nou submeniu în Opțiuni pentru dezvoltatori pentru a comuta rapid schimbările de comportament ale noilor platforme în funcție de aplicație, fără a fi nevoie să trimită comenzi shell ADB. Vor exista secțiuni diferite pentru fiecare nivel API țintă -- de exemplu, nivelul API > 29 va avea propriul set de modificări de comportament care poate fi comutat, în timp ce nivelul API > 30 va avea propriul set de schimbări.
În captura de ecran de mai sus, care prezintă secțiunea Compatibilitate aplicație (de la un AOSP construit din sursă care rulează pe un emulator), „Implicit Secțiunea „Modificări activate” include modificări ale API-ului Android 11 care vor fi activate în mod implicit pentru toate aplicațiile, indiferent de ținta lor SDK. Secțiunea „activată pentru versiunea SDK target > 29” sunt modificări ale API-ului Android 11 care sunt activate numai pentru aplicațiile care vizează Android 11/nivelul API 30.
Deși această schimbare specială nu va entuziasma direct utilizatorii finali, face munca dezvoltatorilor de aplicații mai ușoară și este întotdeauna un lucru bun.
Mulțumim dezvoltatorului recunoscut XDA luca020400 pentru sfat și pentru furnizarea capturii de ecran atașate.
Acoperire suplimentară pe Android 11:
- Android 11 poate elimina în sfârșit limita de dimensiune a fișierelor de 4 GB pentru înregistrările video
- Programarea în modul întunecat ar putea veni în Android 11
- Modul Avion poate opri în sfârșit oprirea sunetului Bluetooth, începând cu Android 11 R
- Google renunță la Android API AsyncTask în Android 11
- Google va face ca dezvoltatorii managerului de fișiere să trimită un formular pentru a obține acces larg la stocarea fișierelor în Android 11
- Android 11 poate aduce în sfârșit o implementare adecvată, nativă a Wireless ADB