Android 11 bo uvedel možnost za razvijalce »Združljivost aplikacij« za pomoč pri testiranju sprememb platforme

Android 11 bo opremljen z novo nastavitvijo »Združljivost aplikacij« v možnostih za razvijalce, kar bo razvijalcem aplikacij olajšalo preizkušanje sprememb vedenja platforme.

Vsako leto na Google I/O Google izpostavi nekaj najbolj vznemirljivih sprememb, ki prihajajo v naslednjo različico Androida. Medtem ko večina uporabnikov ocenjuje različice Androida po vizualnih spremembah, ki vplivajo na njihovo izkušnjo, ima vsaka posodobitev Androida tudi tono spremembe API-jev in obnašanje platforme. Te spremembe so pomembne za razvijalce aplikacij, ki jih morajo upoštevati in nanje pripraviti svoje aplikacije, saj lahko bistveno spremenijo načine, na katere lahko končni uporabniki uporabljajo njihove aplikacije. Z naslednjo različico Androida, Android 11, bo Google razvijalcem olajšal testiranje in pripravo svojih aplikacij na prihajajoče spremembe z novo nastavitvijo »Združljivost aplikacij« v možnostih za razvijalce.

Vsakič, ko Google izda novo različico Androida, razvijalci aplikacij, ki jih zanima, aktivno vzdržujejo njihove aplikacije morajo prebrati nove spremembe in dokumentacijo, ki je zanje priložena spremembe. Nato se lahko odločijo posodobiti svojo aplikacijo in dodati te nove funkcije API-ja, če želijo, ali preseliti svojo uporabo obstoječih API-jev na novejše API-je, pot, ki je lahko izbirna ali pa tudi ne. Razvijalcem aplikacij ni treba takoj posodobiti ciljnega API-ja svojih aplikacij, vendar morajo to storiti sčasoma, da izpolnijo

spreminjanje ciljnih zahtev API-ja trgovine Google Play. Po tem morajo razvijalci tudi dejansko preizkusiti svojo aplikacijo v novi različici Androida, kar je mogoče storiti na emulirani napravi, napravi, ki gostuje v oblaku, ali lokalni napravi. Testiranje je del razvojne rutine, vendar postane testiranje še bolj pomembno, ko gre za večje spremembe.

Nadalje, ko želi Google uvesti večje spremembe v vedenju platforme, spremembe ne izvede takoj v izdaji nove različice Androida. To je namenjeno zaščiti uporabnikov pred tem, da bi se veliko njihovih aplikacij pokvarilo in izgubilo funkcionalnost, poleg tega pa daje razvijalcem več časa za posodobitev svojih aplikacij. Google se je na primer v sistemu Android 7 Nougat odločil, da omeji nekatere implicitne oddaje da prihranite življenjsko dobo baterije. Z Androidom 8 Oreo, Google popolnoma omejil aplikacije pri registraciji implicitnih oddajnih sprejemnikov. Toda preden je bil izdan Android 8 Oreo, je Google želel, da se razvijalci pripravijo na scenarij, ko njihove aplikacije ne bodo več mogle registrirati implicitnih sprejemnikov oddajanja. In za to bi lahko razvijalci uporabite ukaz ADB v sistemu Android 7 Nougat za simulacijo stanja, ko implicitna oddajanja niso na voljo:

adb shell cmd appops set RUN_IN_BACKGROUND ignore

Ukazi ADB, kot je zgornji, so primer, kako Google omogoča razvijalcem aplikacij, da preizkusijo, kako bi se njihove aplikacije obnašale ob spremembah vedenja platforme Android.

Drug nedavni primer je, kako v Androidu Q Beta 2, Google je prosil razvijalce, naj preizkusijo Scoped Storage v njihovih aplikacijah z izvajanjem tega ukaza ADB:

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

Kot razvijalec aplikacij lahko domnevamo, da ste zadovoljni z ukazi ADB in niste ravno naklonjeni njihovi uporabi za preizkušanje teh sprememb platforme. Toda vedno je prostor za izboljšave in Google olajša ta postopek testiranja z uvedbo preprostega uporabniškega vmesnika za nadzor teh sprememb.

Z novim Projekt PlatformCompat, razvijalcem ni več treba izvajati ukazov ADB za vsako novo spremembo vedenja platforme. Z Androidom 11 bo imel Android nov podmeni v možnostih za razvijalce za hitro preklapljanje novih sprememb vedenja platforme na podlagi posamezne aplikacije, ne da bi bilo treba pošiljati ukaze lupine ADB. Za vsako ciljno raven API-ja bodo različni razdelki – na primer raven API-ja> 29 bo imela lasten nabor sprememb vedenja, ki jih je mogoče preklapljati, medtem ko bo raven API > 30 imela svoj nabor spremembe.

Na zgornjem posnetku zaslona, ​​ki prikazuje razdelek o združljivosti aplikacij (iz izvorno zgrajenega AOSP, ki se izvaja v emulatorju), je »Privzeto Razdelek »Omogočene spremembe« vključuje spremembe API-ja za Android 11, ki bodo privzeto omogočene v vseh aplikacijah, ne glede na njihov cilj SDK. Razdelek »omogočeno za targetSDKversion > 29« so spremembe API-ja za Android 11, ki so omogočene samo za aplikacije, ki ciljajo na Android 11/API ravni 30.

Čeprav ta posebna sprememba ne bo neposredno navdušila končnih uporabnikov, olajša delo razvijalcev aplikacij, kar je vedno dobro.


Zahvaljujoč priznanemu razvijalcu XDA luca020400 za nasvet in za zagotavljanje priloženega posnetka zaslona.

Nadaljnja pokritost za Android 11:

  • Android 11 bo morda končno odstranil Androidovo omejitev velikosti datoteke 4 GB za video posnetke
  • Razporejanje temnega načina bi lahko prišlo v Android 11
  • Letalski način bo morda končno prenehal izklapljati zvok Bluetooth, začenši z Androidom 11 R
  • Google opušča Androidov API AsyncTask v sistemu Android 11
  • Google bo razvijalce upravitelja datotek prisilil k predložitvi obrazca za pridobitev širokega dostopa do shranjevanja datotek v sistemu Android 11
  • Android 11 bo morda končno prinesel ustrezno, domačo implementacijo Wireless ADB