Google Play drīzumā piespiedīs izstrādātājus augšupielādēt App Bundle, nevis APK, radot neērtus drošības jautājumus par prasību.
Pagājušā gada novembrī, Google paziņoja ka izstrādātājiem būs jāpublicē jaunas lietotnes Play veikalā, izmantojot Android App Bundle (AAB) formātu, nevis APK. Tikai otro dienu Google atgādināja izstrādātājiem par šo gaidāmo prasību, izraisot strīdu vētru. no lietotājiem, kuri uzskata, ka Google iznīcina APK, novērš sānu ielādi, kavē trešo pušu lietotņu veikalus un kas nu gan.
Tā ir taisnība, ka Android App Bundles ir diezgan liela novirze no klasiskā APK formāta, pie kura, iespējams, esat pieradis gan kā lietotājs, gan kā izstrādātājs. Lai gan lietotņu komplektu izmantošanai ir diezgan daudz priekšrocību, daži izstrādātāji un drošības eksperti ir pamatoti nobažījušies par vienu no galvenajiem to izveides aspektiem.
Šajā rakstā mēs apskatīsim kritiku, ko esam redzējuši par pāreju uz Android App Bundles, kā arī dažus piedāvātos risinājumus, kā arī runāsim par Google piedāvāto risinājumu šīm problēmām.
Fons
Pirms tas notiek, mums nedaudz jāparunā par to, kā lietotņu izplatīšana darbojas operētājsistēmā Android kopumā. Ja jau zināt, kā darbojas lietotņu parakstīšana un lietotņu komplekti, varat izlaist šo daļu.
APK faili
Lielākoties Android lietotnes tiek izplatītas APK failos. APK failā ir ietverts viss lietotnes kods un resursi, kā arī daži drošības līdzekļi, piemēram, parakstīšanas manifests. Kad APK ir instalēts, tas būtībā tiek vienkārši kopēts noteiktā mapē un pievienots instalēto lietotņu iekšējai datubāzei.
Paraksti
Instalēšanas laikā tiek pārbaudīts arī šīs lietotnes paraksts, lai pārliecinātos, ka tas ir derīgs. Ja lietotne jau ir instalēta, Android salīdzina jaunās lietotnes parakstu ar jau instalēto. Ja paraksts nav derīgs vai nesakrīt, Android atteiksies instalēt lietotni.
Šī paraksta pārbaude ir svarīga Android drošības sastāvdaļa. Tas nodrošina, ka instalējamā lietotne ir derīga un vismaz no tā paša avota, no kuras jau instalējāt. Piemēram, ja instalējat, teiksim, mana lietotne Lockscreen Widgets no Play veikala, varat būt diezgan pārliecināts, ka es to parakstīju un ka tas ir autentisks. Ja pēc tam mēģināt instalēt bloķēšanas ekrāna logrīku atjauninājumu no kādas ēnas trešās puses vietnes un tas neizdodas, jūs zināt, ka kāds ir manipulējis ar šo APK, iespējams, lai pievienotu ļaunprātīgu programmatūru.
Lietotnes parakstīšanai izmantotā atslēga (ideālā gadījumā) nekad publiski izlaista. To sauc par privāto atslēgu. Pēc tam privātā atslēga tiek izmantota, lai ģenerētu lietotnes parakstā redzamo atslēgu, kas pazīstama kā publiskā atslēga. To izmanto Android un lietotņu veikali, lai pārbaudītu lietotnes derīgumu. Es nerunāšu par to, kā tieši jūs varat ģenerēt publisko atslēgu, neatklājot privāto atslēgu, jo tas ietver daudz šifrēšanas matemātikas. Ja vēlaties sīkāku informāciju, pārbaudiet Google dokumentācija par APK parakstīšanu vai veikt kādu pētījumu par vienvirziena matemātikas funkcijām.
Vēl viena lietotņu parakstu funkcija ir iespēja ierobežot atļaujas tikai lietotnēm ar atbilstošiem parakstiem. Android to veic iekšēji daudzām funkcijām, kur noteiktām funkcijām var piekļūt tikai lietotnes, kas parakstītas ar to pašu atslēgu kā ietvars.
Lietotņu komplekti
Tagad, kad esam snieguši īsu pārskatu par APK un parakstiem, parunāsim par App Bundle. Šeit tiek izmantoti APK resursi. Resursi ir tādas lietas kā izkārtojumi, attēli, audio utt. Būtībā tie ir jebkas, kas nav kods. Lai labāk atbalstītu dažādas displeja konfigurācijas un dažādas valodas, izstrādātāji var izveidot vairākas viena un tā paša resursa versijas, kas tiek izmantotas atkarībā no ierīces un valodas.
Taču APK failā visi šie resursi pastāv neatkarīgi no tā, kuru izmantojat. Un tie aizņem vietu. Atkarībā no jūsu lietotnes sarežģītības daudzām ierīcēm var būt daudz neizmantotu resursu. Tas ir tas, ko var atrisināt App Bundles. Izstrādātāji var ģenerēt App Bundle tāpat kā APK, un pēc tam šo App Bundle komplektu var augšupielādēt Play veikalā, tāpat kā APK.
Pēc tam Google izmanto šo App Bundle, lai ģenerētu veselu virkni dažādu APK dažādām ierīču konfigurācijām. Katrā App Bundle komplektā ir ietverti tikai šai konfigurācijai nepieciešamie resursi. Kad lietotājs lejupielādē šo lietotni, viņam tiek rādīts ģenerētais APK, kas atbilst viņa konfigurācijai. Tas palīdz samazināt gan lietotņu lejupielādes, gan instalēšanas apjomu, ietaupot joslas platumu un krātuves vietu.
Protams, ja instalējat savai ierīcei specifisku APK failu, jums ir grūtāk to vienkārši pārkopēt uz citu ierīci un bez problēmām instalēt. Atkarībā no jūsu perspektīvas tas var būt labs vai slikts. No vienas puses, tas apgrūtina pirātismu, jo lietotājiem vairs nav visas lietotnes. No otras puses, tā paša iemesla dēļ tas apgrūtina likumīgu lietotņu arhivēšanu.
Lietotņu parakstīšana
Tā kā Android App Bundle pakotnes nav APK faili, jūs nevarat vienkārši atvērt AAB failu un instalēt to tieši ierīcē. Kad augšupielādējat vienu Play veikalā, Google izmanto paketi, lai ģenerētu dažādus (neparakstītus) APK failus. Šie APK ir jāparaksta, pirms tos var instalēt.
Tā vietā, lai lūgtu izstrādātājam parakstīt un atkārtoti augšupielādēt šos ģenerētos APK, Google pārvalda parakstīšanu pats. Play veikals izmanto jaunu atslēgu, ko tas izveido, vai arī pieprasa izstrādātājam parakstīšanai izmantoto atslēgu APK faili. Izmantojot jebkuru iespēju, Google veic izstrādātāja publisko parakstīšanu un nodrošina augšupielādi taustiņu. Google izmanto augšupielādes atslēgu iekšējai verifikācijai un nodrošina, ka izstrādātāja augšupielādētais App Bundle (vai dažos gadījumos APK) ir pareizais.
Ja augšupielādes atslēga tiek apdraudēta vai pazaudēta, izstrādātāji var pieprasīt jaunu, un lietotnes izplatīšanai izmantotā parakstīšanas atslēga paliek nemainīga.
Programmā App Signing ir daudz vairāk, taču tas attiecas uz šo rakstu. Ja vēlaties, varat lasīt vairāk par lietotņu komplektiem un lietotņu pierakstīšanos šis Wojtek Kaliciński raksts Medium.
Kritika
Teorētiski un praksē App Bundle komplekti ir diezgan lieliski. Tie samazina datu lietojumu un instalēšanas apjomu, turklāt lietotājam nekas nav jādara. Bet tā ieviešanas dēļ daži izstrādātāji un drošības pētnieki pēdējos mēnešos ir izteikuši bažas. Pirms apkopoju šīs bažas, es vēlos nedaudz pateikt, ka lielākā daļa no tālāk rakstītā ir tieši pamatojoties uz rakstu sēriju izstrādātājs Marks Mērfijs no CommonsWare. Jums noteikti vajadzētu pārbaudīt viņa rakstus, jo tie sniedz sīkāku informāciju un kritiku no izstrādātāja viedokļa.
Drošība
Klasiskajā izplatīšanas modelī izstrādātājs patur privātu atslēgu, ko izmanto, lai parakstītu APK. Tas nekad netiek kopīgots, un tam ir jābūt tikai pilnvarotām personām. Tas nodrošina, ka tikai šīs personas var ģenerēt derīgu APK.
Taču, ja Play veikalā izmantojat App Bundle komplektus, Google pārvalda atslēgu, kas paraksta lietotāju saņemtos APK. The noklusējuma uzvedību jaunām lietotnēm, kas augšupielādētas pakalpojumā Google Play sākot ar 2021. gada augustu ir Google uzdevums, lai izveidotu savu izplatīšanas atslēgu, ko tas patur privāti no izstrādātāja.
Izstrādātāji iesniedz jaunas lietotnes pēc noklusējuma Google pārvaldīs viņu privāto atslēgu, lai gan izstrādātāji iesniedz atjauninājumus esošās lietotnes var turpināt izmantot APK vai viņi var pārslēgties uz AAB izplatīšanu, ģenerējot jaunu atslēgu, ko Google izmantot jauniem lietotājiem. Esošās lietotnes nav nepieciešamas lai pārslēgtos no APK izplatīšanas uz Android App Bundles, lai gan šī opcija viņiem ir pieejama, ja viņi to izvēlas. Pēc neliela atgrūšanās Google pat padarīs to iespējamu lai augšupielādētu savu privāto atslēgu, lai Google varētu pierakstīties gan jaunām, gan esošām lietotnēm. Neviena no šīm situācijām nav ideāla, jo neatkarīgi no tā, Google varēs piekļūt jūsu privātajai atslēgai, ja vēlaties izmantojiet Android App Bundle komplektus (un izstrādātājiem šajā jautājumā nav izvēles, ja viņi vēlas iesniegt jaunu lietotni pēc augusta 2021!)
Lai gan mēs esam pārliecināti, ka Google ļoti nopietni uztver drošību, pasaulē nav neviena uzņēmuma, kas būtu pasargāts no datu pārkāpumiem. Ja atslēga, ko Google izmanto, lai parakstītu jūsu lietotni izplatīšanai, ir kādā no šiem pārkāpumiem, ikviens var parakstīt jūsu lietotnes versiju un likt tai izskatīties tā, it kā to būtu parakstījis jūs. Un daži izstrādātāji un drošības eksperti nav apmierināti ar šo iespēju. Jā, tā ir ļoti, ļoti maza iespēja, taču fakts, ka tā vispār ir, dažus no infosec kopienas biedē.
Ja izstrādātāji paraksta Android APK, ikviens var verificēt APK failus pakalpojumā Google Play. Aklā uzticēšanās nav nepieciešama. Tas ir elegants dizains, kas nodrošina pārbaudāmu drošību. Lietojumprogrammu komplekti to apvērš, un šķiet, ka tie ir strukturēti tā, lai veicinātu pakalpojumu sniedzēja bloķēšanu. Ir daudzas alternatīvas tehniskas pieejas, kas nodrošinātu mazus APK, ko joprojām parakstījuši izstrādātāji, taču tām nebūtu priekšroka Play. Piemēram, izstrādātājs var ģenerēt un parakstīt visus APK variantus, pēc tam augšupielādēt tos jebkurā lietotņu veikalā.
Noteikti ir jāizsaka argumenti par to, vai privāto atslēgu drošu glabāšanu labāk atstāt Google vai atsevišķu izstrādātāju ziņā. Taču šie izstrādātāji (iespējams) savām atslēgām parasti neizmanto centrālo repozitoriju. Piespiežot izstrādātājus izmantot Play App Signing, ļaunprātīgam uzbrucējam tikai vienreiz ir jāpārkāpj Google drošība, lai izgūtu tūkstošiem vai miljoniem atslēgu.
Lūk, ko Google saka par to, kā tas aizsargā jūsu paraksta atslēgu savā infrastruktūrā.
[blockquote author="Wojtek Kaliciński, Android izstrādātāja advokāts uzņēmumā Google"]Kad izmantojat Play lietotņu parakstīšanu, jūsu atslēgas tiek glabātas tajā pašā infrastruktūrā, ko Google izmanto savu atslēgu glabāšanai.
Atslēgas piekļuvi regulē stingri ACL un pārbaudāmas audita pēdas visām darbībām.
Visi artefakti, kas ģenerēti un parakstīti ar izstrādātāja atslēgu, ir pieejami pakalpojumā Google Play Console pārbaudei/atestācijai.
Turklāt, lai novērstu atslēgu pazaudēšanu, mēs ļoti bieži veicam primārās krātuves dublējumus. Šīs dublējumkopijas ir stingri šifrētas, un mēs regulāri pārbaudām atjaunošanu no šīm dublējumkopijām.
Ja vēlaties uzzināt par Google tehnisko infrastruktūru, izlasiet Google mākoņdrošības dokumenti.[/blockquote]
Lai arī cik lieliski, visas skaņas, nozaudēšana un zādzība joprojām ir iespējama. Un audita pēdas tikai palīdz novērst turpmākus uzbrukumus; viņi nesaņems atpakaļ uzlauztās atslēgas.
Neatļautu modifikāciju iespējamība
Viena liela problēma, kā Google ir iestatījis lietotņu komplektus, ir iespēja, ka lietotnei var tikt pievienotas nesankcionētas modifikācijas. APK failu izvilkšanas process no App Bundle ir saistīts ar modifikācijām, jo uzņēmumam Google ir manuāli jāizveido katrs APK. Kamēr Google ir apsolījis, ka tas neievada un nepārveidos kodu, problēma ar App Bundle procesu ir tā, ka tam ir tiesības to darīt.
Šeit ir daži piemēri tam, ko uzņēmums Google pozīcijā var darīt:
Pieņemsim, ka ir droša ziņojumapmaiņas lietotne, ko cilvēki izmanto, lai sazinātos bez valdības uzraudzības riska. Tas varētu būt neticami noderīgs rīks cilvēkiem, kas protestē pret autoritāru valdību, vai pat cilvēkiem, kuri vienkārši vēlas saglabāt savu privātumu. Šī valdība, kas vēlas redzēt lietotņu lietotāju teikto, varētu mēģināt piespiest Google pievienot novērošanas aizmugures durvis lietotnes kodam.
Šis piemērs ir nedaudz nekaitīgāks, taču tas arī uztrauc dažus cilvēkus. Pieņemsim, ka ir lietotne, kas saņem miljoniem lejupielāžu dienā, taču tajā nav nevienas reklāmas vai analīzes. Tas ir milzīgs datu avots, kuram nav iespējas piekļūt šiem datiem. Google, kas ir reklāmas uzņēmums, iespējams, vēlēsies piekļūt šiem datiem.
Klasiskajā lietotņu izplatīšanas APK modelī Google nevar modificēt lietotnes, nemainot parakstu. Ja Google mainīs parakstu, īpaši populārā lietotnē, cilvēki to pamanīs, jo atjauninājums netiks instalēts. Taču, izmantojot lietotņu komplektus un lietotņu parakstīšanu, Google varēja klusi ievadīt lietotnēs savu kodu pirms to izplatīšanas. Paraksts nemainītos, jo Google pieder parakstīšanas atslēga.
Lai būtu skaidrs, šie piemēri ir ļoti maz ticami. Google mēdz vienkārši izkļūt no traucējošiem tirgiem, nevis pielāgoties. Bet, lai gan tas ir maz ticams, tas joprojām ir iespējams. Tikai tāpēc, ka uzņēmums sola, ka kaut kas nenotiks, tas to negarantē.
Koda caurspīdīgums
Uzklausot šīs bažas, Google šonedēļ ieviesa jaunu funkciju ar nosaukumu Koda caurspīdīgums lietotņu komplektiem. Koda caurspīdīgums ļauj izstrādātājam būtībā izveidot otru parakstu, kas lietotājiem tiek piegādāts kopā ar lietotni. Šis papildu paraksts ir jāizveido no atsevišķas privātās atslēgas, kurai var piekļūt tikai izstrādātājs. Tomēr šai metodei ir daži ierobežojumi.
Koda caurspīdīgums attiecas tikai uz kodu. Tas varētu šķist pašsaprotami, ņemot vērā nosaukumu, taču tas arī nozīmē, ka tas neļauj lietotājiem pārbaudīt resursus, manifestu vai jebko citu, kas nav DEX fails vai vietējā bibliotēka. Lai gan ļaunprātīgām nekoda failu modifikācijām parasti ir daudz mazāka ietekme, tas joprojām ir robs lietotnes drošībā.
Vēl viena koda caurspīdīguma problēma ir tāda, ka tai nav raksturīgas verifikācijas. Vienam, tā ir izvēles funkcija, tāpēc izstrādātājiem tas ir jāiekļauj katrā jaunajā augšupielādētajā APK. Šobrīd tas ir jādara no komandrindas un ar versiju bundletool kas nav iekļauts Android Studio komplektācijā. Pat ja izstrādātājs to iekļauj, Android ierīcē nav iebūvēta nekāda veida verifikācija, lai pārbaudītu, vai Code Transparency manifests atbilst lietotnes kodam.
Galalietotājam pašam ir jāpārbauda, salīdzinot manifestu ar publisko atslēgu, ko var nodrošināt izstrādātājs, vai nosūtot APK failu izstrādātājam verifikācijai.
Lai gan Code Transparency ļauj apstiprināt, ka neviens lietotnes kods nav mainīts, tajā nav iekļauta nekāda veida verifikācija citām lietotnes daļām. Procesam nav arī raksturīgas uzticēšanās. Jūs varētu iebilst, ka, ja neuzticaties uzņēmumam Google, jūs, iespējams, veicat neatkarīgu verifikāciju, bet kāpēc tas būtu jādara?
Ir arī citas problēmas ar funkciju Code Transparency, piemēram, norādīja Marks Mērfijs no CommonsWare. Iesaku izlasīt viņa rakstu, lai padziļināti analizētu funkciju.
Izstrādātāja ērtības un izvēle
Trešais (un pēdējais šim rakstam) iemesls, kāpēc daži izstrādātāji sastopas ar App Bundle komplektiem, ir samazinātas ērtības un izvēle.
Ja izstrādātājs Play veikalā izveido jaunu lietotni pēc tam, kad Google sāk pieprasīt App Bundle komplektus un viņš to izvēlas noklusējuma opcija ļaut Google pārvaldīt parakstīšanas atslēgu, viņi nekad nevarēs piekļūt šai parakstīšanai taustiņu. Ja tas pats izstrādātājs vēlas izplatīt šo lietotni citā lietotņu veikalā, viņam būs jāizmanto sava atslēga, kas neatbilst Google atslēgai.
Tas nozīmē, ka lietotājiem būs jāinstalē un jāatjaunina no Google Play vai trešo pušu avotiem. Ja viņi vēlas mainīt avotu, viņiem ir pilnībā jāatinstalē lietotne, iespējams, tiek zaudēti dati, un atkārtoti jāinstalē. APK apkopotājiem patīk APKMirror tad būs jātiek galā arī ar vairākiem oficiāliem parakstiem par vienu un to pašu lietotni. (Tehniski viņiem tas jau ir jādara, jo lietotņu parakstīšana ļauj izveidot jaunu, drošāku atslēgu jauniem lietotājiem, taču viņiem un citām vietnēm būs sliktāk, kad visi ir lai to izdarītu.)
Google atbilde uz šo problēmu ir Play Console izmantot App Bundle Explorer vai Artifact Explorer, lai lejupielādētu iegūtos APK failus no augšupielādētā komplekta. Līdzīgi kā Code Transparency, tas nav pilnīgs risinājums. No Play Console lejupielādētie APK faili tiks sadalīti dažādiem ierīču profiliem. Lai gan Play Console atbalsta vairāku APK failu augšupielādi vienai lietotnes versijai, daudzi citi izplatīšanas kanāli to neatbalsta.
Tādējādi daudzas App Bundle izmantošanas priekšrocības pazūd, kad izstrādātāji pārvalda vairākus veikalus, padarot izplatīšanu grūtāku. Ar ziņām, ka Windows 11 ir Android lietotņu atbalsta iegūšana pateicoties Amazon Appstore, daži uzskata, ka App Bundles prasība atturēs izstrādātājus no izplatīšanas vietnē Amazon. Protams, Google galvenās rūpes ir par savu lietotņu veikalu, taču tas ir tieši tas nosēdināja tos karstā ūdenī kopā ar konkurentiem liekot viņiem taisīt nelielas, samiernieciskas izmaiņas kā trešo pušu lietotņu veikali darbojas operētājsistēmā Android.
Dažas ar vairākiem veikaliem saistītas problēmas ir lietotņu savstarpēja savienojamība un ātrās darbības pārbaude.
Sāksim ar lietotņu savstarpējo savienojamību. Vai esat kādreiz lejupielādējis lietotni, kas bloķē funkcijas aiz maksas sienas? Gandrīz noteikti. Daži izstrādātāji izmanto šīs funkcijas, veicot pirkumu lietotnē, bet citi var izvēlēties izveidot atsevišķu maksas lietotni. Kad šī pievienojumprogramma tiek instalēta, galvenās lietotnes funkcijas tiek atbloķētas.
Bet kas neļauj kādam vienkārši instalēt papildinājumu no pirātu avota? Izstrādātājiem ir daudz iespēju, taču vismaz viena ietver ar parakstu aizsargātu atļauju izmantošanu. Pieņemsim, ka galvenā lietotne deklarē ar parakstu aizsargātu atļauju. Pēc tam pievienojumprogramma paziņo, ka vēlas izmantot šo atļauju. Ideālā gadījumā pievienojumprogrammai būs arī sava veida licences verifikācijas funkcionalitāte, kas izveido savienojumu ar internetu, lai pārliecinātos, ka lietotājs ir likumīgs.
Ja abām lietotnēm ir vienāds paraksts, Android piešķirs atļauju pievienojumprogrammai un tiks veiktas pirātisma aizsardzības pārbaudes. Ja pievienojumprogrammai nav pareizā paraksta, atļauja netiks piešķirta un verifikācija neizdosies.
Izmantojot klasisko APK izplatīšanas modeli, lietotājs var iegūt jebkuru lietotni no jebkura likumīga avota un tikt galā ar to. Izmantojot pašreizējo noklusējuma App Bundle modeli, paraksti galvenajā un papildprogrammā nesakritīs. Google katrai lietotnei izveidos unikālu atslēgu. Izstrādātājs vienmēr var atteikties no ar parakstu aizsargātas atļaujas un izmantot tiešu paraksta jaukšanas verifikāciju, taču tas ir daudz mazāk droši.
Un tad ir ātrās uguns testēšana. Lietotāji pastāvīgi sūta izstrādātājiem e-pasta ziņojumus par problēmām viņu lietotnēs. Dažkārt šīs problēmas var atrisināt vienkārši: atkārtojiet problēmu, atrodiet problēmu, izlabojiet to un augšupielādējiet jaunu versiju. Bet dažreiz tie nav. Dažreiz izstrādātāji nevar atveidot problēmu. Viņi var novērst, viņuprāt, problēmu, bet pēc tam lietotājam tā ir jāpārbauda. Tagad pieņemsim, ka lietotājs instalēja lietotni, izmantojot pakalpojumu Google Play.
Izmantojot APK modeli, izstrādātājs var mainīt kādu kodu, izveidot un parakstīt jaunu APK un nosūtīt to lietotājam pārbaudei. Tā kā testa APK paraksts atbilst lietotāja instalētajam, atjaunināšana, pārbaude un ziņošana ir vienkāršs process. Izmantojot App Bundles, tas izjūk. Tā kā Google paraksta lietotāja sākotnēji instalēto APK, tas neatbilst izstrādātāja nosūtītā APK parakstam. Ja šī lietotne tiks publicēta pēc App Bundles termiņa beigām, izstrādātājam pat nebūs piekļuves Google izmantotajām atslēgām. Lai veiktu testēšanu, lietotājam pirms testa versijas instalēšanas ir jāatinstalē pašreizējā lietotne.
Šeit ir daudz problēmu. Pirmkārt, ir neērtības gan izstrādātāja, gan lietotāja pusē. Lietotne ir jāatinstalē tikai, lai pārbaudītu labojumu, nav jautri. Un ko darīt, ja problēma pazūd? Vai tās bija izstrādātāja veiktās izmaiņas vai tāpēc, ka lietotājs efektīvi notīrīja lietotnes datus? Play veikalā ir iekšējā testēšana, kas paredzēta, lai izstrādātāji varētu ātri izveidot un izplatīt, taču lietotājam vispirms ir jāatinstalē laidiena versija. Tas īsti neko nelabo.
Ja tas viss izklausās pēc hipotētiskas muļķības, šeit ir ļoti reāls piemērs izstrādātājam, kuram radīsies šīs problēmas, ja viņš ļaus Google ģenerēt viņiem privāto atslēgu: João Dias. Viņš ir Tasker izstrādātājs kopā ar daudzām spraudņu lietotnēm, tostarp AutoApps komplektu. Ņemot vērā jauno lietotņu komplektu prasību, João izstrādes cikls var kļūt daudz sarežģītāks, vismaz jaunām lietotnēm. Testēšanas versiju tieša nosūtīšana būs mazāk ērta. Licenču pārbaude būs mazāk efektīva.
Tas var šķist nedaudz niecīgs gadījums, taču nav tā, ka Žoau ir mazs izstrādātājs un, visticamāk, viņš nav viens. Play veikalā ir daudz lietotņu, kas paļaujas uz paraksta verifikāciju, lai atklātu nelikumīgus lietotājus.
Protams, ar jauno iespēju izstrādātājiem augšupielādēt savas parakstīšanas atslēgas Google tīklā, šīs problēmas ir vismaz nedaudz atvieglotas. Taču izstrādātājiem ir jāizvēlas, lai iespējotu šo opciju katrai lietotnei. Ja tas nenotiek, starpsavienojumi neizdosies, un ātras darbības atbalstam būs nepieciešams augšupielādēt komplektu Google tīklā un gaidīt, līdz tiek ģenerēti APK, pirms tiks nosūtīts pareizais fails lietotājam. Turklāt tas joprojām nozīmē, ka viņiem ir jādala sava privātā atslēga, kas mūs atgriež pie iepriekš apspriestajām bažām.
Risinājumi
Tā ir veca problēma, jo App Bundle prasības tika publicētas pirms mēnešiem, tāpēc pa šo laiku ir piedāvāti vairāki risinājumi.
Viens no risinājumiem ir izvairīties no nepieciešamības pēc Play lietotņu parakstīšanas. Tā vietā, lai ģenerētu App Bundle, ko Google pēc tam apstrādā APK failos un zīmēs, šo apstrādi var veikt Android Studio. Pēc tam izstrādātāji var vienkārši augšupielādēt ZIP failu, kas pilns ar lokāli parakstītiem APK failiem katrai konfigurācijai, ko Google būtu ģenerējis.
Izmantojot šo risinājumu, Google nemaz nebūtu nepieciešama piekļuve izstrādātāju atslēgām. Process būtu ļoti līdzīgs klasiskajam APK izplatīšanas modelim, taču tajā būtu iesaistīti vairāki mazāki APK, nevis tikai viens.
Vēl viens risinājums ir vienkārši nepieprasīt lietotņu komplektu izmantošanu un turpināt ļaut izstrādātājiem augšupielādēt lokāli parakstītus APK. Lai gan App Bundles var daudzos gadījumos sniedz lietotājam labāku pieredzi, dažas lietotnes faktiski negūst labumu no sadalīšanas atbilstoši konfigurācijai ar minimālu izmēru samazināšana.
Ja Google ieviesa abus šos risinājumus, izstrādātājam, kurš vēlas izmantot App Bundle komplektus, nebūs pārrakstoties ar Google, un izstrādātājam, kura lietotne negūs lielu labumu no formāta, tas nebūs jāizmanto visi.
Google atbildes
Pašparakstīšanās
Kad viņiem pirmo reizi tika jautāts, vai ļaut izstrādātājiem veikt parakstīšanu App Bundle komplektiem, Google atbilde bija ļoti neuzkrītoša:
[blockquote author=""]Tātad, es īsi runāju par prasību nākamajā gadā jaunajām lietotnēm izmantot lietotņu komplektus, un viena lieta, kas ir saistīta ar to, ir tāda, ka līdz ar to mums būs nepieciešama Play lietotņu parakstīšana. Tāpēc izstrādātājiem būs vai nu jāģenerē lietotņu parakstīšanas atslēga pakalpojumā Play, vai arī jāaugšupielādē sava atslēga pakalpojumā Play… jo tas ir priekšnoteikums lietotņu komplektiem. Mēs esam dzirdējuši no izstrādātājiem, ka daži no viņiem vienkārši nevēlas to darīt. Viņi nevēlas, lai atslēgas pārvaldītu Play. Un pašlaik tas nav iespējams, ja vēlaties izmantot lietotņu komplektus.
Taču mēs esam dzirdējuši šīs atsauksmes, un... Es šobrīd nevaru ne par ko runāt, mums nav par ko paziņot, taču mēs pētām, kā mēs varētu mazināt dažas no šīm bažām. Tam nav obligāti jāļauj saglabāt savu atslēgu, augšupielādējot paketi. Mēs izskatām dažādas iespējas. Mums vienkārši šobrīd nav risinājuma, ko paziņot. Taču mums vēl ir aptuveni gads līdz prasībai, tāpēc es ļoti ceru, ka mums būs atbilde izstrādātājiem šajā jautājumā.[/blockquote]
Tas bija pagājušā gada novembra beigās, un šķiet, ka nekas nav noticis. Palikuši tikai daži mēneši līdz Stājas spēkā App Bundles prasība, izstrādātājiem joprojām nav iespējas parakstīt savas lietotnes. Lai gan Google tagad ir ļāvusi augšupielādēt savu atslēgu gan jaunajām, gan esošajām lietotnēm, tas joprojām izņem parakstīšanas daļu no izstrādātāja rokās.
Koda izmaiņas
Lai gan Google ir īpaši apsolījis, ka Play veikals nemainīs lietotnes kodu, solījums nav garantija. Izmantojot lietotņu komplektus un lietotņu parakstīšanu, mums nav nekādu tehnisku ierobežojumu, kas neļautu Google pārveidot augšupielādētās lietotnes pirms izplatīšanas.
Google ir ieviesusi Koda caurspīdīgums kā izvēles līdzekli, un, lai gan tas zināmā mērā palīdz, tai ir sava daļa problēmu, kā mēs apspriedām iepriekš.
Pašdarināti komplekti
Kad uzņēmumam Google tika jautāts, vai ļaut izstrādātājiem izveidot savus lietotņu komplektus (ZIP, kas satur sadalītus APK), atbilde būtībā bija "mēs to nedarīsim".
Iespējams, ne tā, kā aprakstīts jautājumā, jo tas izstrādātājiem padarītu publicēšanas procesu vēl grūtāku, un mēs patiesībā vēlamies to padarīt vienkāršāku un drošāku. Tomēr mēs atkal esam dzirdējuši šīs atsauksmes un izskatīsim iespējas, kā to padarīt iespējamu, taču, iespējams, ne tādā veidā, kā šeit aprakstīts.
Interesanti, ka Google pamatojums šķiet tāds, ka tas padarītu publicēšanu sarežģītāku. Tomēr Google joprojām varētu padarīt procesu automatizētu, izmantojot Android Studio APK ģenerēšanas dialoglodziņu. Turklāt, ja attiecīgā lietotne tiek izplatīta vairākos veikalos, tas faktiski radītu publicēšanas process ir vienkāršāks, jo izstrādātājiem nebūs jāpārvalda vairākas parakstīšanas atslēgas un sūdzības no lietotājiem.
Un, ieviešot Code Transparency, šķiet, ka sarežģījumi galu galā nav problēma. Koda pārskatāmība vismaz pagaidām paredz, ka izstrādātājam ir jāizmanto komandrindas rīks un lietotājiem ir skaidri jāpārbauda piedāvātās lietotnes derīgums. Tas ir sarežģītāks nekā pašizveidošanas process, un nav skaidrs, kāpēc Google dod priekšroku šim risinājumam.
Iet uz priekšu
Sākot ar 1. augustu, lietotņu komplekti būs obligātais izplatīšanas formāts jaunajām lietotnēm, kas iesniegtas pakalpojumā Google Play. Lai gan Google ir vismaz nedaudz atrisinājusi lielāko daļu izstrādātāju un drošības ekspertu izvirzīto problēmu, atbildes atstāj daudz ko vēlēties. App Bundle kā nākamās paaudzes izplatīšanas formātam ir daudz acīmredzamu priekšrocību, taču vienmēr būs bažas par daļējas vai pilnīgas lietotņu parakstīšanas kontroles piešķiršanu uzņēmumam Google.
Google atbildes un centieni noteikti tiek novērtēti, taču daži, piemēram, Marks Mērfijs, uzskata, ka viņi nav tikuši pietiekami tālu. Tā kā risinājumi, piemēram, pašizveidotie komplekti, netiek ieviesti un Android App Bundle komplektu termiņš ir ātrs tuvojas, neizskatās, ka izstrādātāji pakalpojumā Google Play uz ilgu laiku varēs saglabāt pilnīgu kontroli pār savām lietotnēm ilgāk.
Vēlāk šopēcpusdien Twitter telpā runāsim par Android App Bundle prasības sekām, tāpēc pievienojieties mums!