Az Android 11 új „Alkalmazás-kompatibilitás” beállítással érkezik a Fejlesztői opcióban, ami megkönnyíti az alkalmazásfejlesztők számára a platform viselkedésében bekövetkezett változások tesztelését.
A Google minden évben a Google I/O rendezvényen kiemeli az Android következő verziójának legizgalmasabb változásait. Míg a legtöbb felhasználó az élményt befolyásoló vizuális változások alapján ítéli meg az Android-verziókat, minden Android-frissítéshez is tartozik egy csomó módosítások az API-kban és platform viselkedését. Ezek a változtatások fontosak az alkalmazásfejlesztők számára, hogy tudomásul vegyék és felkészítsék alkalmazásaikat, mivel alapvetően megváltoztathatják azt a módot, ahogyan alkalmazásaikat a végfelhasználók fogyaszthatják. Az Android következő verziójával, az Android 11-gyel a Google megkönnyíti a fejlesztők számára, hogy teszteljék és felkészítsék alkalmazásaikat a közelgő változásokra a Fejlesztői beállítások új „Alkalmazáskompatibilitás” beállításával.
Minden alkalommal, amikor a Google kiad egy új Android-verziót, az alkalmazásfejlesztők, akik érdeklődnek az aktív karbantartás iránt alkalmazásaiknak tájékozódniuk kell az új változásokról és az ezekhez kapcsolódó dokumentációról változtatások. Ezt követően dönthetnek úgy, hogy frissítik az alkalmazásukat, hogy hozzáadják ezeket az új API-funkciókat, ha szeretnének, vagy áttelepíthetik a meglévő API-k használatát újabb API-kra. Ez az elérési út opcionális vagy nem kötelező. Az alkalmazásfejlesztőknek nem kell azonnal frissíteniük alkalmazásaik cél API-ját, de végül meg kell tenniük, hogy megfeleljenek a
a Google Play Áruház cél API követelményeinek eltolódása. Ezt követően a fejlesztőknek az új Android-verzión is ténylegesen tesztelniük kell az alkalmazásukat, és ez megtehető emulált eszközön, felhőalapú eszközön vagy helyi eszközön. A tesztelés a fejlesztési rutin része, de a tesztelés még fontosabbá válik, ha jelentős változásokról van szó.Továbbá, amikor a Google jelentős változtatásokat szeretne bevezetni a platform viselkedésében, nem hajtja végre azonnal a változást az új Android-verzióban. Ez megóvja a felhasználókat attól, hogy sok alkalmazásuk elromoljon és elveszítse a funkcionalitást, és a fejlesztőknek több idejük marad az alkalmazásaik frissítésére. Például az Android 7 Nougat esetében a Google úgy döntött korlátozni néhány implicit adást az akkumulátor élettartamának megtakarítása érdekében. Android 8 Oreo rendszerrel, Google teljesen megtiltotta, hogy az alkalmazások implicit műsorszóró vevőket regisztráljanak. Az Android 8 Oreo megjelenése előtt azonban a Google azt akarta, hogy a fejlesztők készüljenek fel arra a forgatókönyvre, amikor az alkalmazásaik nem lesznek képesek implicit adásvevőket regisztrálni. És erre a fejlesztők tehettek használjon ADB-parancsot az Android 7 Nougat rendszerben egy olyan állapot szimulálására, amikor az implicit adások nem érhetők el:
adb shell cmd appops set RUN_IN_BACKGROUND ignoreA fentihez hasonló ADB-parancsok példák arra, hogy a Google hogyan teszi lehetővé az alkalmazásfejlesztők számára, hogy teszteljék, hogyan viselkednének alkalmazásaik az Android-platform viselkedésének megváltozása esetén.
Egy másik közelmúltbeli példa, hogy az Android Q Beta 2-ben A Google felkérte a fejlesztőket, hogy teszteljék a Scoped Storage szolgáltatást az alkalmazásaikban az ADB parancs futtatásával:
adb shell cmd appops set your-package-name android: legacy_storage default && \Alkalmazásfejlesztőként feltételezhető, hogy kényelmesen kezeli az ADB-parancsokat, és nem különösebben idegenkedsz attól, hogy ezeket a platformmódosításokat teszteld. De mindig van hova fejlődni, és a Google megkönnyíti ezt a tesztelési folyamatot azáltal, hogy egy egyszerű felhasználói felületet vezet be a változtatások vezérlésére.
Az újjal PlatformCompat projekt, a fejlesztőknek többé nem kell ADB-parancsokat futtatniuk minden egyes új platform viselkedési változásához. Az Android 11 esetén az Android egy új almenüvel rendelkezik a Fejlesztői beállítások között, amellyel gyorsan átkapcsolhatja az új platform viselkedésének változásait alkalmazásonként, anélkül, hogy ADB-héjparancsokat kellene küldenie. Minden egyes cél API-szinthez különböző szakaszok lesznek – például a 29-nél nagyobb API-szint lesz saját viselkedésmódosítási halmaza, amely átkapcsolható, míg a 30-as API-szintnél saját készlete lesz változtatások.
A fenti képernyőképen, amely az Alkalmazás-kompatibilitás szakaszt mutatja (egy emulátoron futó forrásból épített AOSP-ből), az „Alapértelmezett Engedélyezett módosítások" szakasz tartalmazza az Android 11 API módosításait, amelyek alapértelmezés szerint minden alkalmazásban engedélyezve lesznek, függetlenül a céltól. SDK. Az „Enabled for targetSDKversion > 29” szakasz az Android 11 API módosításait tartalmazza, amelyek csak az Android 11/API 30-as szintjét célzó alkalmazások esetében engedélyezettek.
Ez a változás ugyan nem fogja közvetlenül izgatni a végfelhasználókat, de megkönnyíti az alkalmazásfejlesztők dolgát, és ez mindig jó.
Köszönet az XDA elismert fejlesztőjének luca020400 a tippért és a mellékelt képernyőkép biztosításához.
További lefedettség Android 11-en:
- Az Android 11 végre eltávolíthatja az Android 4 GB-os fájlméret-korlátját a videofelvételeknél
- A sötét mód ütemezése az Android 11-ben jelenhet meg
- Az Android 11 R-től kezdve a Repülőgép mód végre leállíthatja a Bluetooth-hangot
- A Google megszünteti az Android AsyncTask API-ját az Android 11-ben
- A Google arra készteti a fájlkezelő fejlesztőket, hogy küldjenek be egy űrlapot, hogy széles körű hozzáférést kapjanak a fájltároláshoz az Android 11 rendszerben
- Az Android 11 végre megfelelő, natív vezeték nélküli ADB megvalósítást hozhat