A Google Play hamarosan arra kényszeríti a fejlesztőket, hogy APK-k helyett App Bundle csomagokat töltsenek fel, ami kényelmetlen biztonsági kérdéseket vet fel a feltétellel kapcsolatban.
Tavaly novemberben, A Google bejelentette hogy a fejlesztőknek az APK helyett Android App Bundle (AAB) formátumban kell új alkalmazásokat közzétenniük a Play Áruházban. Épp a napokban a Google emlékeztette a fejlesztőket erre a közelgő követelményre, és ezzel vitavihart robbantott ki. olyan felhasználóktól, akik azt hiszik, hogy a Google megöli az APK-kat, megszünteti az oldalbetöltést, akadályozza a harmadik féltől származó alkalmazásboltokat, és miegymás.
Igaz, hogy az Android App Bundle csomagok meglehetősen nagy eltérést jelentenek a klasszikus APK formátumtól, amelyet felhasználóként és fejlesztőként is megszokhat. Noha az App Bundle csomagok használatának számos előnye van, van egy kulcsfontosságú szempont a létrehozásukban, ami miatt néhány fejlesztő és biztonsági szakértő jogosan aggódik.
Ebben a cikkben kitérünk az Android App Bundle csomagokra való átállással kapcsolatos kritikákra, valamint néhány javasolt megoldásra, valamint szót ejtünk a Google által ezekre a problémákra javasolt megoldásról is.
Háttér
Mielőtt azonban ez megtörténne, beszélnünk kell egy kicsit arról, hogyan működik az alkalmazásterjesztés általában az Androidon. Ha már ismeri az alkalmazás-aláírás és az alkalmazáscsomagok működését, akkor ezt a részt kihagyhatja.
APK-k
Az Android-alkalmazások többnyire APK-fájlokon belül vannak elosztva. Az APK tartalmazza az alkalmazás összes kódját és erőforrásait, valamint néhány biztonsági funkciót, például egy aláírási jegyzéket. Amikor egy APK telepítve van, alapvetően csak egy adott mappába másolja, és hozzáadja a telepített alkalmazások belső adatbázisához.
Aláírások
A telepítés során az alkalmazás aláírását is ellenőrzik, hogy megbizonyosodjanak arról, hogy az érvényes. Ha az alkalmazás már telepítve van, az Android összeveti az új alkalmazás aláírását a már telepített aláírással. Ha az aláírás nem érvényes vagy nem egyezik, az Android megtagadja az alkalmazás telepítését.
Az aláírás-ellenőrzés az Android biztonságának fontos része. Győződjön meg arról, hogy a telepített alkalmazás érvényes, és legalább ugyanabból a forrásból származik, mint a már telepített. Például, ha telepíti, mondjuk a Lockscreen Widgets alkalmazásomat a Play Áruházból, elég biztos lehet benne, hogy én írtam alá, és hogy hiteles. Ha ezután megpróbál egy frissítést telepíteni a Lockscreen Widget-ekre valamilyen árnyékos, harmadik féltől származó webhelyről, és ez nem sikerül, akkor tudni fogja, hogy valaki manipulálta az APK-t, valószínűleg rosszindulatú program hozzáadása céljából.
Az alkalmazás aláírásához használt kulcs (ideális esetben) soha nyilvánosan kiadták. Ezt privát kulcsnak nevezik. A privát kulcsot ezután az alkalmazás aláírásában látható kulcs létrehozására használják, amely nyilvános kulcsként ismert. Az Android és az alkalmazásboltok ezt használják az alkalmazások érvényességének ellenőrzésére. Arra nem térek ki, hogy pontosan hogyan lehet nyilvános kulcsot generálni a privát kulcs felfedése nélkül, mivel ez sok titkosítási matematikát igényel. Ha további részletekre van szüksége, nézze meg A Google dokumentációja az APK-k aláírásáról vagy végezzen kutatást az egyirányú matematikai függvényekkel kapcsolatban.
Az alkalmazás-aláírások másik jellemzője, hogy csak a megfelelő aláírásokkal rendelkező alkalmazásokra korlátozhatja az engedélyeket. Az Android sok funkciónál ezt belsőleg teszi meg, ahol csak a keretrendszerrel azonos kulccsal aláírt alkalmazások férhetnek hozzá bizonyos funkciókhoz.
Alkalmazáscsomagok
Tehát most, hogy adtunk egy gyors áttekintést az APK-król és az aláírásokról, beszéljünk az App Bundle csomagokról. Itt jönnek be az APK-források. Az erőforrások olyan dolgok, mint az elrendezések, képek, hanganyagok stb. Alapvetően minden olyan dolog, ami nem kód. A különböző megjelenítési konfigurációk és nyelvek jobb támogatása érdekében a fejlesztők az eszköztől és a nyelvtől függően több verziót is elkészíthetnek ugyanabból az erőforrásból.
De egy APK-ban ezek az erőforrások mindegyike létezik, függetlenül attól, hogy melyiket használja. És helyet foglalnak. Az alkalmazás összetettségétől függően sok eszköznél sok kihasználatlan erőforrás lehet. Ennek megoldására készültek az App Bundle csomagok. A fejlesztők ugyanúgy létrehozhatnak egy App Bundle csomagot, mint egy APK-t, és ezt az App Bundle csomagot az APK-hoz hasonlóan feltölthetik a Play Áruházba.
A Google ezután ezt az App Bundle csomagot arra használja, hogy egy csomó különböző APK-t generáljon a különböző eszközkonfigurációkhoz. Minden App Bundle csomag csak az adott konfigurációhoz szükséges erőforrásokat tartalmazza. Amikor a felhasználó letölti az alkalmazást, a rendszer megkapja a konfigurációjának megfelelő generált APK-t. Ez segít csökkenteni az alkalmazások letöltési és telepítési méretét, sávszélességet és tárhelyet takarítva meg.
Természetesen egy speciális APK telepítése az eszközére azt jelenti, hogy nehezebb egyszerűen átmásolni egy másik eszközre, és probléma nélkül telepíteni. Az Ön nézőpontjától függően ez lehet jó vagy rossz dolog. Egyrészt megnehezíti a kalózkodást, mivel a felhasználók már nem rendelkeznek a teljes alkalmazással. Másrészt ugyanezen okból megnehezíti az alkalmazások jogos archiválását.
Alkalmazás aláírása
Mivel az Android App Bundle csomagok nem APK-k, nem nyithat meg egyszerűen egy AAB-fájlt, és telepítheti közvetlenül az eszközre. Amikor feltölt egyet a Play Áruházba, a Google a csomag segítségével különböző (aláíratlan) APK-fájlokat generál. Ezeket az APK-kat ezután alá kell írni, mielőtt telepíthetők.
Ahelyett, hogy megkérné a fejlesztőt, hogy írja alá és töltse fel újra a generált APK-kat, a Google maga kezeli az aláírást. A Play Áruház vagy egy általa létrehozott új kulcsot használ, vagy a fejlesztőtől kéri az aláíráshoz használt kulcsot APK-k. Mindkét lehetőség esetén a Google kezeli a fejlesztő nyilvános aláírását, és biztosítja a feltöltést kulcs. A Google a feltöltési kulcsot használja a belső ellenőrzéshez, és gondoskodik arról, hogy a fejlesztő által feltöltött App Bundle (vagy bizonyos esetekben APK) a megfelelő legyen.
Ha egy feltöltési kulcs sérül vagy elveszik, a fejlesztők újat kérhetnek, és az alkalmazás terjesztéséhez használt aláíró kulcs változatlan marad.
Az Alkalmazás-aláírás még sok mindenről szól, de ebben a cikkben ez a lényeges. Ha szeretné, további információkat olvashat az App Bundle csomagokról és az alkalmazásbejelentkezésről ez a Medium cikk Wojtek Kalicińskitól.
Kritika
Elméletileg és a gyakorlatban az App Bundle csomagok nagyon nagyszerűek. Csökkentik az adathasználatot és a telepítés méretét, mindezt anélkül, hogy a felhasználónak bármit is tennie kellene. De a megvalósítás módja miatt néhány fejlesztő és biztonsági kutató az elmúlt hónapokban aggodalmát fejezte ki. Mielőtt összefoglalnám ezeket az aggodalmakat, szeretnék egy pillanatra elmondani, hogy az alábbiakban leírtak nagy része közvetlenül szól cikksorozat alapján a fejlesztő Mark Murphy CommonsWare. Feltétlenül nézze meg a cikkeit, mert a fejlesztő szemszögéből több részletet és kritikát tartalmaznak.
Biztonság
A klasszikus terjesztési modellben a fejlesztők magánként tartják meg az APK aláírásához használt kulcsot. Soha nem osztják meg a nyilvánossággal, és csak arra jogosult személyek férhetnek hozzá. Ez biztosítja, hogy csak ezek a személyek generálhassanak érvényes APK-t.
De ha App Bundle csomagokat használ a Play Áruházban, akkor a Google kezeli a kulcsot, amely aláírja a felhasználók által kapott APK-kat. A alapértelmezett viselkedését a Google Playre feltöltött új alkalmazások esetében 2021 augusztusától A Google-nak létre kell hoznia a saját terjesztési kulcsát, amelyet titokban tart a fejlesztőtől.
A fejlesztők beküldik új alkalmazások alapértelmezés szerint a Google kezeli a privát kulcsukat, bár a fejlesztők frissítéseket küldenek be meglévő alkalmazások folytathatja az APK-k használatát vagy átválthatnak az AAB-terjesztésre, ha új kulcsot generálnak a Google számára, amelyet az új felhasználók számára használhat. Meglévő alkalmazások nem kötelezőek átváltani az APK-terjesztésről az Android App Bundle csomagokra, bár ez a lehetőség elérhető számukra, ha úgy döntenek. Némi visszahúzás után a Google még azt is lehetővé teszi saját privát kulcsának feltöltéséhez, amellyel a Google bejelentkezhet, mind az új, mind a meglévő alkalmazásokhoz. Ezen helyzetek egyike sem ideális, hiszen bármi is legyen, a Google hozzáférhet az Ön privát kulcsához, ha akarja használja az Android App Bundle csomagokat (és a fejlesztőknek nincs más választásuk, ha augusztus után új alkalmazást szeretnének benyújtani 2021!)
Bár biztosak vagyunk abban, hogy a Google nagyon komolyan veszi a biztonságot, a Földön nincs olyan vállalat, amely mentes lenne az adatszivárgástól. Ha a Google által az alkalmazásod terjesztési aláírásához használt kulcs a jogsértések valamelyikében található, akkor bárki aláírhatja az alkalmazás egy verzióját, és úgy tűnhet, mintha Ön írta volna alá. Néhány fejlesztő és biztonsági szakértő pedig nem örül ennek a lehetőségnek. Igen, nagyon-nagyon csekély lehetőség, de a tény, hogy egyáltalán van rá lehetőség, megrémít néhányat az infosec közösségben.
Ha a fejlesztők aláírják az Android APK-kat, az azt jelenti, hogy bárki ellenőrizheti az APK-kat a Google Playről, nincs szükség vak bizalomra. Ez egy elegáns kialakítás, amely ellenőrizhető biztonságot nyújt. Az App Bundle-csomagok ezt a feje tetejére állítják, és úgy tűnik, hogy úgy vannak kialakítva, hogy elősegítsék a szolgáltatók bezárását. Számos alternatív technikai megközelítés létezik, amelyek kis APK-kat biztosítanak, amelyeket még mindig a fejlesztők írnak alá, de ezek nem részesítik előnyben a Playt. Például a fejlesztő az összes APK-változatot létrehozhatja és aláírhatja, majd feltöltheti bármelyik alkalmazásboltba.
Minden bizonnyal vitathatóak, hogy jobb-e a privát kulcsok biztonságos tárolását a Google vagy az egyes fejlesztők kezében hagyni. De ezek a fejlesztők (valószínűleg) általában nem használnak központi tárolót a kulcsaikhoz. Ha a fejlesztőket a Play App Signing használatára kényszeríti, a rosszindulatú támadónak csak egyszer kell feltörnie a Google biztonságát, hogy több ezer vagy millió kulcsot lekérhessen.
Hogy mennyit ér, a Google elmondja, hogyan védi az Ön aláíró kulcsát az infrastruktúrájában:
[blockquote author="Wojtek Kaliciński, Android Developer Advocate a Google-nál"]A Play App Signing használatakor a kulcsok ugyanazon az infrastruktúrán tárolódnak, amelyet a Google a saját kulcsainak tárolására használ.
A kulcsokhoz való hozzáférést szigorú ACL-ek és minden műveletre vonatkozó hamisítás-ellenőrző nyomvonal szabályozzák.
A fejlesztői kulccsal generált és aláírt összes műtermék elérhetővé válik a Google Play Console-ban ellenőrzés/tanúsítás céljából.
Továbbá a kulcs elvesztésének megelőzése érdekében nagyon gyakran készítünk biztonsági másolatot elsődleges tárhelyünkről. Ezek a biztonsági mentések erősen titkosítottak, és rendszeresen teszteljük a visszaállítást ezekből a biztonsági másolatokból.
Ha többet szeretne megtudni a Google műszaki infrastruktúrájáról, olvassa el a Google Cloud Security Whitepapers.[/blockquote]
Bármilyen nagyszerű is, minden hang, az elvesztés és a lopás továbbra is lehetséges. Az ellenőrzési nyomvonalak pedig csak a jövőbeni támadások megelőzésében segítenek; nem kapják vissza a törött kulcsokat.
Jogosulatlan módosítások lehetősége
Az egyik nagy probléma azzal kapcsolatban, ahogyan a Google beállította az App Bundle csomagokat, az az, hogy jogosulatlan módosításokat lehet hozzáadni az alkalmazásokhoz. Az APK-k App Bundle csomagból való kinyerésének folyamata eleve módosításokkal jár, mivel a Google-nak manuálisan kell létrehoznia minden APK-t. Míg A Google megígérte, hogy nem szúr be és nem is módosít kódot, az a probléma az App Bundle folyamattal, hogy képes erre.
Íme néhány példa arra, hogy a Google pozíciójában lévő vállalat mire képes:
Tegyük fel, hogy létezik egy biztonságos üzenetküldő alkalmazás, amellyel az emberek a kormányzati felügyelet kockázata nélkül kommunikálnak. Ez hihetetlenül hasznos eszköz lehet azoknak, akik tiltakoznak egy tekintélyelvű kormány ellen, vagy akár olyanok számára is, akik csak meg akarják őrizni magánéletüket. Ez a kormány, aki látni akarja, mit mondanak az alkalmazás felhasználói, megpróbálhatja rákényszeríteni a Google-t, hogy adjon hozzá egy felügyeleti hátsó ajtót az alkalmazás kódjához.
Ez a példa egy kicsit ártalmatlanabb, de bizonyos embereket ez is aggaszt. Tegyük fel, hogy van egy alkalmazás, amelyet naponta több millió letöltés ér, de nincsenek benne hirdetések vagy elemzések. Ez egy hatalmas adatforrás, amelyhez nem lehet hozzáférni. A Google, mint reklámcég, esetleg hozzá szeretne férni ezekhez az adatokhoz.
Az alkalmazásterjesztés klasszikus APK-modelljében a Google nem tudja módosítani az alkalmazásokat az aláírás megváltoztatása nélkül. Ha a Google megváltoztatja az aláírást, különösen egy népszerű alkalmazáson, az emberek észre fogják venni, mert a frissítés nem települ. Az App Bundle csomagokkal és az App Signing szolgáltatással azonban a Google csendben beillesztheti saját kódját az alkalmazásokba, mielőtt elosztaná azokat. Az aláírás nem változna, mert a Google birtokolja az aláíró kulcsot.
Hogy világos legyen, ezek a példák hihetetlenül valószínűtlen, hogy megtörténjenek. A Google hajlamos egyszerűen teljesen kivonulni a problémás piacokról, nem pedig alkalmazkodni. De bár valószínűtlen, mégis lehetséges. Csak azért, mert egy cég megígéri, hogy valami nem fog megtörténni, még nem garantálja.
Kód átláthatósága
A Google, hallva ezeket az aggodalmakat, ezen a héten bevezetett egy új funkciót, az úgynevezett Átlátszó kód az App Bundle csomagokhoz. A Code Transparency lehetővé teszi a fejlesztő számára, hogy lényegében létrehozzon egy második aláírást, amelyet az alkalmazással együtt szállítanak a felhasználóknak. Ezt az extra aláírást külön privát kulcsból kell létrehozni, amelyhez csak a fejlesztő férhet hozzá. Ennek a módszernek azonban vannak korlátai.
A kód átláthatósága csak a kódra vonatkozik. Ez a név alapján magától értetődőnek tűnhet, de azt is jelenti, hogy a felhasználók nem ellenőrizhetik az erőforrásokat, a jegyzéket vagy bármi mást, ami nem DEX-fájl vagy natív könyvtár. Míg a nem kódolt fájlok rosszindulatú módosításainak általában sokkal kisebb a hatása, ez még mindig lyukat jelent az alkalmazás biztonságában.
A Code Transparency másik problémája az, hogy nincs benne rejlő ellenőrzés. egyrészt ez egy opcionális funkció, így a fejlesztőknek nem szabad elfelejteniük, hogy minden feltöltött új APK-nál fel kell tüntetniük. Jelenleg ezt a parancssorból és egy verziójával kell megtenni bundletool ez nem tartozik az Android Stúdióhoz. Még akkor sem, ha egy fejlesztő felveszi, az Android nem rendelkezik beépített ellenőrzéssel annak ellenőrzésére, hogy a Code Transparency jegyzék egyezik-e az alkalmazás kódjával.
A végfelhasználóknak kell ellenőrizniük saját maguk a jegyzéket a fejlesztő által biztosított nyilvános kulccsal, vagy elküldik az APK-t a fejlesztőnek ellenőrzésre.
Míg a Code Transparency lehetővé teszi annak megerősítését, hogy az alkalmazásban lévő kódok nem módosulnak, az alkalmazás más részeire vonatkozóan nem tartalmaz semmilyen ellenőrzést. A folyamatban nincs benne rejlő bizalom sem. Lehet vitatkozni azzal, hogy ha nem bízik a Google-ban, akkor valószínűleg képes az önálló ellenőrzésre, de miért kellene?
Más problémák is vannak a Code Transparency funkcióval, mint pl rámutatott írta: Mark Murphy CommonsWare. Javaslom, hogy olvassa el cikkét a funkció mélyebb elemzéséhez.
Fejlesztői kényelem és választék
A harmadik (és ebben a cikkben az utolsó) ok, amiért egyes fejlesztők vitatják az App Bundle csomagokat, a csökkent kényelem és választék.
Ha egy fejlesztő új alkalmazást készít a Play Áruházban, miután a Google elkezdi igényelni az App Bundle csomagokat, és úgy dönt Az alapértelmezett lehetőség, hogy a Google kezelje az aláíró kulcsot, soha nem férhetnek hozzá az aláíráshoz kulcs. Ha ugyanaz a fejlesztő az alkalmazást egy másik alkalmazásboltban szeretné terjeszteni, akkor a saját kulcsát kell használnia, amely nem egyezik meg a Google kulcsával.
Ez azt jelenti, hogy a felhasználóknak vagy a Google Playről vagy harmadik féltől származó forrásokból kell telepíteniük és frissíteniük. Ha módosítani akarják a forrást, teljesen el kell távolítaniuk az alkalmazást, ami adatvesztést okozhat, majd újra kell telepíteniük. Az APK aggregátorok kedvelik APKMirror ezután több hivatalos aláírással is meg kell küzdenie ugyanahhoz az alkalmazáshoz. (Technikailag ezt már meg kell tenniük, mert az App Signing segítségével új, biztonságosabb kulcsot hozhat létre az új felhasználók számára, de ez rosszabb lesz nekik és más webhelyeknek, ha mindenki van csinálni.)
A Google válasza erre a problémára az, hogy a Play Console App Bundle-böngészőjét vagy Artifact-felfedezőjét használja a kapott APK-k letöltéséhez a feltöltött csomagból. A Code Transparencyhez hasonlóan ez sem teljes megoldás. A Play Console-ból letöltött APK-k különböző eszközprofilokhoz lesznek felosztva. Míg a Play Console támogatja több APK feltöltését egy alkalmazás egy verziójához, sok más terjesztési csatorna nem.
Így az App Bundle csomagok használatának sok előnye megszűnik, ha a fejlesztők több áruházat kezelnek, ami megnehezíti a terjesztést. Azzal a hírrel Windows 11 van Android alkalmazások támogatásának megszerzése az Amazon Appstore-nak köszönhetően egyesek úgy vélik, hogy az App Bundle követelményei visszatartják a fejlesztőket az Amazonon való terjesztéstől. Természetesen a Google elsődleges gondja a saját alkalmazásboltja, de pontosan erről van szó forró vízben landolta őket a versenyzőkkel készítésére készteti őket apró, békéltető változtatások hogy hogyan működnek a harmadik féltől származó alkalmazásboltok Androidon.
A több üzlettel kapcsolatos néhány probléma az alkalmazások összekapcsolhatósága és a gyorstesztelés.
Kezdjük az alkalmazások összekapcsolhatóságával. Letöltöttél már olyan alkalmazást, amely fizetőfal mögé zárja a funkciókat? Majdnem biztosan. Egyes fejlesztők a funkciókat az alkalmazáson belüli vásárlás mögé helyezik, de mások dönthetnek úgy, hogy különálló, fizetős alkalmazást készítenek. A kiegészítő alkalmazás telepítése után a fő alkalmazás funkciói feloldódnak.
De mi akadályozza meg, hogy valaki csak kalóz forrásból telepítse a kiegészítőt? Nos, sok lehetőség van a fejlesztők számára, de legalább az egyik magában foglalja az aláírással védett engedélyek használatát. Tegyük fel, hogy a fő alkalmazás aláírással védett engedélyt deklarál. A kiegészítő alkalmazás ezután kijelenti, hogy használni kívánja ezt az engedélyt. Ideális esetben a kiegészítő alkalmazás tartalmaz egyfajta licenc-ellenőrző funkciót is, amely csatlakozik az internethez, hogy megbizonyosodjon arról, hogy a felhasználó jogos.
Ha mindkét alkalmazásnak ugyanaz az aláírása, az Android megadja az engedélyt a kiegészítő alkalmazásnak, és a kalózkodás elleni védelem ellenőrzése sikeres lesz. Ha a bővítményalkalmazás nem rendelkezik megfelelő aláírással, az engedélyt nem adjuk meg, és az ellenőrzés sikertelen lesz.
A klasszikus APK terjesztési modellel a felhasználó bármelyik alkalmazást beszerezheti bármely legitim forrásból, és el is végezheti vele. A jelenlegi alapértelmezett App Bundle-modellnél a fő és a kiegészítő alkalmazások aláírásai nem egyeznek. A Google minden alkalmazáshoz egyedi kulcsot fog készíteni. A fejlesztő bármikor megszüntetheti az aláírással védett engedélyt, és közvetlen aláírás-kivonat-ellenőrzést alkalmazhat, de ez sokkal kevésbé biztonságos.
Aztán jön a gyorstüzelés. A felhasználók folyamatosan e-mailt küldenek a fejlesztőknek az alkalmazásaikkal kapcsolatos problémákról. Néha ezek a problémák egyszerű javítások: reprodukálja a problémát, keresse meg a problémát, javítsa ki, és töltsön fel egy új verziót. De néha nem. Néha a fejlesztők nem tudják reprodukálni a problémát. Meg tudják javítani azt, amit a problémának gondolnak, de utána a felhasználónak tesztelnie kell. Tegyük fel, hogy a felhasználó a Google Playen keresztül telepítette az alkalmazást.
Az APK-modellel a fejlesztő módosíthat bizonyos kódokat, új APK-t készíthet és írhat alá, majd elküldheti a felhasználónak tesztelésre. Mivel a teszt-APK aláírása megegyezik a felhasználó által telepített aláírással, a frissítés, a tesztelés és a visszajelzés egyszerű folyamat. Az App Bundle csomagokkal ez szétesik. Mivel a Google aláírja azt az APK-t, amelyet a felhasználó eredetileg telepített, az nem egyezik meg a fejlesztő által küldött APK aláírásával. Ha ezt az alkalmazást az App Bundle csomagok határideje után teszik közzé, a fejlesztő még a Google által használt kulcsokhoz sem fog hozzáférni. A teszteléshez a felhasználónak el kell távolítania az aktuális alkalmazást a tesztverzió telepítése előtt.
Van itt egy csomó probléma. Először is kellemetlenségek vannak, mind a fejlesztői, mind a felhasználói oldalon. Az alkalmazás eltávolítása pusztán a javítás tesztelése érdekében nem szórakoztató. És mi van, ha a probléma megszűnik? A fejlesztő változtatásai miatt, vagy azért, mert a felhasználó ténylegesen törölte az alkalmazás adatait? A Play Áruház rendelkezik belső teszteléssel, amely állítólag lehetővé teszi a fejlesztők számára a gyors felépítést és terjesztést, de ehhez először el kell távolítania a kiadási verziót. Nem igazán javít semmit.
Abban az esetben, ha ez az egész egy csomó hipotetikus hülyeségnek hangzik, itt van egy nagyon valós példa egy fejlesztőre, akinek ezekkel a problémákkal kell szembenéznie, ha hagyja, hogy a Google privát kulcsot generáljon nekik: João Dias. Ő a Tasker fejlesztője, egy csomó beépülő alkalmazással együtt, beleértve az AutoApps csomagot is. Az új App Bundles követelmény miatt João fejlesztési ciklusa sokkal bonyolultabbá válhat, legalábbis az új alkalmazások esetében. A tesztverziók közvetlen elküldése kevésbé lesz kényelmes. A licencek ellenőrzése kevésbé lesz hatékony.
Ez kissé szélsőségesnek tűnhet, de nem mintha João valami kis fejlesztő lenne, és valószínűleg nincs egyedül. A Play Áruházban sok olyan alkalmazás található, amelyek aláírás-ellenőrzésre támaszkodnak a törvénytelen felhasználók észleléséhez.
Természetesen az új lehetőség, hogy a fejlesztők saját aláíró kulcsaikat feltölthetik a Google-ba, ezek a problémák legalább valamelyest enyhülnek. A fejlesztőknek azonban fel kell iratkozniuk, hogy engedélyezzék ezt a lehetőséget az egyes alkalmazásokhoz. Ha nem teszik meg, az összekapcsolás meghiúsul, és a gyorsindítási támogatáshoz egy csomagot kell feltölteni a Google-ba, és meg kell várni az APK-k generálását, mielőtt elküldené a megfelelőt a felhasználónak. Ráadásul ez továbbra is azt jelenti, hogy meg kell osztaniuk a privát kulcsukat, ami visszavezet minket a korábban tárgyalt aggályokhoz.
Megoldások
Ez egy régi probléma, mivel az App Bundle követelményeit hónapokkal ezelőtt nyilvánosságra hozták, így időközben jó néhány megoldást javasoltak.
Az egyik megoldás az, hogy elkerüljük a Play App Signing alkalmazását. Ahelyett, hogy létrehozna egy App Bundle csomagot, amelyet a Google ezután APK-kká és aláírásokká dolgoz fel, ezt a feldolgozást az Android Studio is elvégezheti. Ezután a fejlesztők feltölthetnek egy ZIP-t, tele helyileg aláírt APK-kkal minden konfigurációhoz, amelyet a Google generált volna.
Ezzel a megoldással a Google-nak egyáltalán nem kellene hozzáférnie a fejlesztői kulcsokhoz. A folyamat nagyon hasonló lenne a klasszikus APK-terjesztési modellhez, de több, kisebb APK-t érintene egyetlen helyett.
Egy másik megoldás az, hogy egyszerűen nem szükséges az App Bundle csomagok használata, és továbbra is lehetővé teszik a fejlesztők számára, hogy helyileg aláírt APK-kat töltsenek fel. Míg az App Bundle csomagok esetleg sok esetben jobb élményt nyújt a felhasználó számára, bizonyos alkalmazásoknak valójában nem származik előnye a konfigurációnkénti felosztásból, minimális mérettel csökkentés.
Ha a Google mindkét megoldást megvalósította, akkor az App Bundle csomagokat használni kívánó fejlesztőnek nem kell túl bejelentkezik a Google-hoz, és annak a fejlesztőnek, akinek az alkalmazása nem sokat profitál a formátumból, nem kell használnia minden.
A Google válaszai
Önaláírás
Amikor először megkérdezték őket arról, hogy engedélyezik-e a fejlesztőknek az App Bundle csomagok aláírását, a Google válasza nagyon nem volt kötelező:
[blockquote author=""]Tehát röviden beszéltem arról, hogy jövőre az új alkalmazásoknak alkalmazáscsomagokat kell használniuk, és egy dolog, ami ezzel együtt jár, az, hogy kibővítve szükség lesz a Play App Signing szolgáltatásra. Tehát a fejlesztőknek vagy elő kell állítaniuk az alkalmazás-aláíró kulcsot a Playen, vagy fel kell tölteniük saját kulcsukat a Playre… mert ez az alkalmazáscsomagok előfeltétele. Azt hallottuk a fejlesztőktől, hogy néhányan egyszerűen nem akarják megtenni. Nem akarják, hogy a kulcsokat a Play kezelje. És jelenleg ez nem lehetséges, ha alkalmazáscsomagokat szeretne használni.
De hallottuk ezt a visszajelzést, és… Jelenleg nem beszélhetek semmiről, nincs bejelenteni valónk, de azt vizsgáljuk, hogyan tudnánk enyhíteni ezen aggodalmakon. Nem feltétlenül kell lehetővé tennie a saját kulcs megtartását a csomagok feltöltése közben. Különböző lehetőségeket vizsgálunk. Csak éppen most nincs bejelenteni való megoldásunk. De még körülbelül egy évünk van a követelményig, ezért nagyon remélem, hogy választ kapunk erre a fejlesztők számára.[/blockquote]
Ez tavaly november végén volt, és úgy tűnik, semmi sem történt. Már csak néhány hónap volt hátra a Az alkalmazáscsomagokra vonatkozó követelmény életbe lép, még mindig nincs mód a fejlesztők számára, hogy kezeljék saját alkalmazásaik aláírását. Míg a Google most lehetővé tette feltölteni saját kulcsa mind az új, mind a meglévő alkalmazásokhoz, ez továbbra is kiveszi az aláírási részt a fejlesztő kezéből.
Kódmódosítások
Bár a Google kifejezetten megígérte, hogy a Play Áruház nem fogja módosítani az alkalmazás kódját, az ígéret nem garancia. Az App Bundle csomagokkal és az App Signing szolgáltatással nincs tudomásunk szerint olyan technikai korlát, amely megakadályozná a Google-t abban, hogy a terjesztés előtt módosítsa a feltöltött alkalmazásokat.
A Google bemutatta Kód átláthatósága opcionális szolgáltatásként, és bár ez némileg segít, megvan a maga része a problémáknak, amint azt korábban tárgyaltuk.
Saját készítésű kötegek
Amikor a Google-t arról kérdezték, hogy engedélyezik-e a fejlesztők számára saját alkalmazáscsomagjaik (osztott APK-kat tartalmazó ZIP-ek) létrehozását, a válasz alapvetően az volt, hogy "ezt nem fogjuk megtenni":
Valószínűleg nem úgy, ahogy a kérdésben le van írva, mivel ez még megnehezítené a közzétételi folyamatot a fejlesztők számára, és valójában szeretnénk egyszerűbbé és biztonságosabbá tenni. Azonban ismét hallottuk ezt a visszajelzést, és megvizsgáljuk a lehetőségeket, hogyan tehetjük ezt lehetővé, de valószínűleg nem az itt leírt módon.
Érdekes módon a Google indoklása szerint az bonyolultabbá tenné a publikálást. A Google azonban továbbra is automatizálhatja a folyamatot az Android Studio APK-generálási párbeszédpaneljének részeként. Továbbá, ha a kérdéses alkalmazást több áruházban terjesztik, akkor valójában a a közzétételi folyamat egyszerűbb, mivel a fejlesztőknek nem kell több aláírási kulcsot és panaszt kezelniük felhasználókat.
És a Code Transparency bevezetésével úgy tűnik, hogy a bonyodalmak mégsem jelentenek problémát. A Code Transparency legalább egyelőre megköveteli a fejlesztőtől, hogy parancssori eszközt használjon, a felhasználóknak pedig kifejezetten ellenőrizniük kell a kiszolgált alkalmazás érvényességét. Ez bonyolultabb, mint a csomagok saját készítésének folyamata, és nem világos, hogy a Google miért ezt a megoldást részesíti előnyben.
Előre menni
Az App Bundle csomagok lesznek a szükséges terjesztési formátumok a Google Playre benyújtott új alkalmazások esetében augusztus 1-től. Bár a Google legalább valamennyire foglalkozott a fejlesztők és biztonsági szakértők által felvetett problémák többségével, a válaszok sok kívánnivalót hagynak maga után. Az App Bundle csomagok, mint a következő generációs terjesztési formátumok számos nyilvánvaló előnnyel járnak, de mindig maradandó aggályok merülnek fel azzal kapcsolatban, hogy az alkalmazás-aláírás részleges vagy teljes ellenőrzését a Google-nak adja át.
A Google válaszait és erőfeszítéseit minden bizonnyal nagyra értékeljük, de egyesek, mint például Mark Murphy, úgy érzik, nem mentek el elég messzire. Olyan megoldásokkal, mint a saját készítésű csomagok, amelyeket nem vezetnek be, és az Android App Bundle csomagok határidejét gyorsan leírják közeledik, nem úgy tűnik, hogy a Google Play fejlesztői sokáig képesek lesznek megtartani az alkalmazásaik feletti teljes ellenőrzést hosszabb.
Az Android App Bundle követelmény következményeiről ma délután egy Twitter-területen fogunk beszélni, úgyhogy csatlakozzon hozzánk!