Az AOSP-ben végrehajtott véglegesítések szerint a Google korlátozhatja a hozzáférést a nem dokumentált vagy rejtett API-khoz az Android P rendszerben. Sok márkanevű alkalmazás rejtett API-kat használ a funkciók bővítésére, így a hatás széles körben elterjedt lehet.
Frissítés 2018.02.28: A Google ma közzétett egy blogbejegyzést, amely megerősíti a változásokat. További részletek a cikk végén.
Míg néhány Android-rajongó igen spekulál milyen desszertről kapja majd a nevét az Android következő verziója, érdekes fejlemények zajlanak a kulisszák mögött. Észrevettük a kevés figyelemre méltó Az Android P közelgő funkciói, de az Android Open Source Project (AOSP) újabb felfedezése sokkal érdekesebbnek bizonyult. A legutóbbi véglegesítések szerint az alkalmazások korlátozhatják az Android SDK-ban nem dokumentált API-k elérését (például a javadoc @hide attribútuma által megjelölt API-k esetében).
Miért számít ez
Az Android Software Development Kit (SDK) API-könyvtárakat és eszközöket biztosít a fejlesztőknek, amelyekre szükségük van az új Android-alkalmazások teszteléséhez és létrehozásához. Az Android minden egyes új kiadásával új API-k egész sora érkezik, amelyek az Android SDK-n keresztül állnak a fejlesztők rendelkezésére. Az alkalmazások számára elérhető API-k attól függnek, hogy a fejlesztő milyen SDKV-verziót állít be. Ezért a Google-é
Google házigazdák dokumentációs oldalak minden osztályhoz és minden API-szinten elérhető metódusához. Ezek a dokumentált API-k készletei, amelyek elérhetők a hivatalos Android SDK-ban. Könnyedén böngészhet az osztályok listájában egy Android-alkalmazással, például az Android Engineer által nemrég kiadott Android SDK Search alkalmazással. Jake Wharton.
Ár: Ingyenes.
4.1.
Azonban nem minden Android-kiadásban elérhető API-t dokumentált a Google, vagy nem érhető el a hivatalos Android SDK-ban. Gyakran vannak hasznos API-k iratokkal nem rendelkező, de ennek ellenére nagyon hasznosak. Nem ajánlott, hogy a fejlesztők dokumentálatlan vagy rejtett API-k segítségével készítsék alkalmazásaikat, de sokan ezt teszik, mert egyszerűen nincs más lehetőség, ha egy bizonyos funkciót szeretnének kínálni. A rejtett vagy nem dokumentált API-kat használó fejlesztők versenyelőnyhöz is juthatnak, hiszen olyan szolgáltatásokat tudnak kínálni, mint versenytársaik – akik ragaszkodnak az Android által kínált API-khoz SDK – nem.
Bár nem tudok listát adni a nem dokumentált API-kat használó alkalmazásokról (a fejlesztők valószínűleg nem osztják meg hogy melyiket használják, mert ez feldobná a versenytársakat), a lista valószínűleg inkább nagy. Így arra a következtetésre jutok, hogy a rejtett API-khoz való hozzáférés tiltása jelentős lenne. Mark Murphy, az alapító Commonsware, egyetért:
Egyetértek azzal az értékeléssel, hogy a @elrejtés megjegyzésekkel ellátott elemekhez való hozzáférés tömeges tiltása nagy baj lesz, ha ez megtörténik. Remélhetőleg kevés alkalmazás éri el ezeket az elemeket a legfontosabb funkciók részeként. Mindazonáltal gyanítom, hogy sok márkás alkalmazás használja ezeket alkalmanként, közvetlenül vagy könyvtáron keresztül.
Mi történik az Android P-ben?
Ezeket a közelgő változásokat először az XDA Senior Recognized Developer vette észre rovo89, a fejlesztő a Xposed Framework. Két elkötelezettségre mutatott rám, az egyikre melyik volt összeolvadt, amely bemutat egy új, „hiddenapi” összeállítási eszközt. Ez az eszköz módosítja az összes osztálytag hozzáférési jelzőjét egy DEX fájlon belül, ha aláírásaik megjelennek egy bemeneti szürkelistán vagy feketelistán, és ha igen, a megjelölt metódusokat a rendszer belső API-ként kezeli, korlátozottan hozzáférés. A másik commit az API feketelista működését írja le; megakadályozza a hozzáférést bakancs osztály a fent említett „hiddenapi”-vel jelölt metódusok és mezők, amelyeket a fejlesztők statikus hivatkozással, tükrözéssel és JNI-vel érhetnek el.
A rovo89 szerint az Android P két változásának végeredménye a következő:
Ha ezeket a véglegesítéseket összevonják, az azt jelentené, hogy az alkalmazások többé nem használhatnak/férhetnek hozzá rejtett API-khoz, azaz osztályok, metódusok és mezők, amelyek @hide megjegyzéssel vannak ellátva az AOSP-ben, és ezért nem részei a hivatalos SDK. Ez nem jelentene problémát az Xposed moduloknál, mivel könnyen visszaállíthatnám ezeket a véglegesítéseket, vagy megengedhetném a moduloknak, hogy elérheti ezeket az API-kat. De sok olyan alkalmazás van, amely kihasználja a rejtett API-kat, és ezek meghibásodnak jövő.
Valójában a további kötelezettségvállalások azt mutatják, hogy a Google ezt tervezi. Ez elkövetni a következőket mondja ki:
Bár ez a konkrét commit nem került összevonásra, mivel 3 kisebb commit javára elhagyták, a véglegesítési üzenet leírja a változtatások célját. Egy másik készlet vállalja megmutatja, hogy a Google alternatívákat fog javasolni azoknak a fejlesztőknek, akik nem nyilvános API-kat kívánnak használni:
Bizonyos rejtett API-knak azonban gyakran nincs alternatívája. Mi az XDA-nál tapasztalatból tudunk beszélni Sajnos ez a változás néhány innovatív alkalmazás végét jelentheti, vagy szükség lehet néhány nagynevű alkalmazásra, hogy csökkentsék funkcionalitás. Ez a közelgő változás szellemében hasonlónak tűnik a legutóbbihoz az akadálymentesítési szolgáltatások elleni fellépés (ez volt szerencsére szüneteltetve ahogy a Google értékelte az innovatív felhasználásokat). Míg a legtöbb nem dokumentált API-t használó alkalmazás jóindulatú okokból teszi ezt, előfordulhatnak olyan alkalmazások, amelyek aljas célokra visszaéltek velük.
Emiatt előfordulhat, hogy a Google letiltja a hozzáférést az összes rejtett API-hoz az Android P-ben, hogy megvédje a felhasználókat azoktól, akik visszaélnek velük. Nehéz megmondani, hogy ez mekkora hatással lehet a felhasználókra, de ha Ön fejlesztő fontolóra veszi, hogy az AOSP-n keresztül keressen egy rejtett API innovatív alkalmazását, akkor érdemes lehet átgondolni.
Frissítés: a Google megerősíti
Az a blog bejegyzés február 28-án, a Google megerősítette ezeket a változtatásokat. A felhasználókat fenyegető összeomlási kockázatokra hivatkozva, majd a fejlesztők sürgősségi javítások bevezetésére kényszerítve, a Google kijelenti, hogy a vállalat fokozatosan eltántorítja a fejlesztőket attól, hogy hozzáférjenek a nem SDK-hoz interfészek. Az Android P-től kezdve a korlátozások kiterjednek az SDK Java nyelvi felületeire is.
A vállalat kijelenti, hogy "néhány nem SDK-módszer és mező korlátozva lesz", bár nem részletezték, hogy melyek lesznek korlátozva. Kezdetben a korlátozás a ritkán használt interfészekre irányul majd, és egy ideig a cég megengedi A fejlesztők továbbra is használjanak nem SDK-módszereket és -mezőket, ahol az SDK-módszerre való átállás technikailag indokolt kihívást jelentő. A korlátozások azonban idővel szélesedni fognak, ezért a nem SDK-módszereket használó alkalmazások fejlesztőinek a lehető leghamarabb át kell állniuk az Android P-re való felkészülés során. Ami az SDK-alternatíva nélküli módszereket illeti, a Google arra kéri a fejlesztőket, hogy tegyenek közzé bejegyzéseket hibakövető további információkkal.
A következő, látszólag hamarosan érkező fejlesztői előzetes lehetővé teszi a fejlesztők számára, hogy a végleges kiadás előtt teszteljék a meglévő alkalmazásokat a fekete- vagy szürkelistán.