Google Play va forța în curând dezvoltatorii să încarce App Bundle-uri în loc de APK-uri, ridicând întrebări de securitate incomode cu privire la cerință.
În noiembrie anul trecut, Google a anunțat dezvoltatorilor li se va cere să publice aplicații noi în Magazinul Play folosind formatul Android App Bundle (AAB) în loc de un APK. Chiar zilele trecute, Google le-a reamintit dezvoltatorilor această cerință viitoare, declanșând o furtună de controverse de la utilizatori care cred că Google ucide APK-urile, elimină încărcarea laterală, împiedică magazinele de aplicații terță parte și fleacuri.
Este adevărat că Android App Bundle-urile reprezintă o abatere destul de mare de la formatul APK clasic cu care ați putea fi obișnuit, atât ca utilizator, cât și ca dezvoltator. Deși există destul de multe beneficii în folosirea pachetelor de aplicații, există un aspect cheie în crearea acestora, care îi preocupă pe bună dreptate pe unii dezvoltatori și experți în securitate.
În acest articol, vom acoperi criticile pe care le-am văzut cu privire la trecerea la Android App Bundle, precum și unele soluții propuse și vom vorbi, de asemenea, despre soluția propusă de Google pentru aceste probleme.
fundal
Înainte de a se întâmpla asta, trebuie să vorbim puțin despre modul în care funcționează distribuția aplicațiilor pe Android în general. Dacă știți deja cum funcționează semnarea aplicațiilor și App Bundle-urile, puteți sări peste această parte.
APK-uri
În cea mai mare parte, aplicațiile de pe Android sunt distribuite în interiorul fișierelor APK. Un APK conține tot codul și resursele unei aplicații, împreună cu unele funcții de securitate, cum ar fi un manifest de semnare. Când este instalat un APK, acesta este practic doar copiat într-un folder specific și adăugat la o bază de date internă a aplicațiilor instalate.
Semnături
În timpul instalării, semnătura aplicației respective este, de asemenea, verificată pentru a vă asigura că este validă. Dacă aplicația este deja instalată, Android verifică semnătura noii aplicații cu cea care este deja instalată. Dacă semnătura nu este validă sau nu se potrivește, Android va refuza să instaleze aplicația.
Verificarea semnăturii este o parte importantă a securității în Android. Se asigură că aplicația pe care o instalați este validă și cel puțin din aceeași sursă cu cea pe care ați instalat-o deja. De exemplu, dacă instalați, să spunem, aplicația mea Widgeturi Lockscreen din Magazinul Play, poți fi sigur că eu sunt cel care l-a semnat și că este autentic. Dacă apoi încercați să instalați o actualizare pentru Lockscreen Widgets de pe un site terț umbrit și nu reușește, veți ști că cineva a manipulat acel APK, eventual pentru a adăuga malware.
Cheia folosită pentru a semna o aplicație este (ideal) nu eliberat public. Aceasta este cunoscută sub numele de cheie privată. Cheia privată este apoi folosită pentru a genera cheia afișată în semnătura aplicației, cunoscută sub numele de cheie publică. Acesta este ceea ce Android și magazinele de aplicații folosesc pentru a verifica validitatea unei aplicații. Nu voi înțelege cum exact puteți genera o cheie publică fără a expune cheia privată, deoarece implică multă matematică de criptare. Dacă doriți mai multe detalii, verificați Documentația Google despre semnarea APK-urilor sau faceți niște cercetări cu privire la funcțiile matematice unidirecționale.
O altă caracteristică a semnăturilor aplicațiilor este capacitatea de a restricționa permisiunile numai la aplicațiile cu semnături potrivite. Android face acest lucru intern pentru o mulțime de funcții, în care numai aplicațiile semnate cu aceeași cheie ca cadrul pot accesa anumite funcții.
Pachetele de aplicații
Așa că acum că am oferit o scurtă prezentare generală a APK-urilor și a semnăturilor, să vorbim despre App Bundle. Aici intervin resursele APK. Resursele sunt lucruri precum machete, imagini, audio etc. Practic, sunt orice nu este cod. Pentru a suporta mai bine diferite configurații de afișare și limbi diferite, dezvoltatorii pot crea mai multe versiuni ale aceleiași resurse care sunt utilizate în funcție de dispozitiv și de limbă.
Dar într-un APK, toate aceste resurse există, indiferent de ce folosiți. Și ocupă spațiu. În funcție de complexitatea aplicației dvs., ar putea exista o mulțime de resurse neutilizate pentru o mulțime de dispozitive. Acesta este ceea ce sunt făcute pentru a rezolva App Bund-urile. Dezvoltatorii pot genera un App Bundle la fel ca un APK, iar acel App Bundle poate fi apoi încărcat în Magazinul Play, la fel ca un APK.
Google folosește apoi acel App Bundle pentru a genera o mulțime de APK-uri diferite pentru diferite configurații de dispozitiv. Fiecare App Bundle conține doar resursele necesare pentru configurația respectivă. Când un utilizator merge să descarce aplicația respectivă, i se oferă APK-ul generat care se potrivește cu configurația sa. Acest lucru ajută la reducerea atât a dimensiunilor de descărcare, cât și de instalare a aplicației, economisind lățime de bandă și spațiu de stocare.
Desigur, instalarea unui APK specific dispozitivului dvs. înseamnă că vă este mai greu să îl copiați pe alt dispozitiv și să îl instalați fără probleme. În funcție de perspectiva ta, acesta poate fi un lucru bun sau rău. Pe de o parte, face pirateria mai dificilă, deoarece utilizatorii nu mai au întreaga aplicație. Pe de altă parte, face mai dificilă arhivarea legitimă a aplicațiilor, din același motiv.
Semnarea aplicației
Deoarece Android App Bundle nu sunt APK-uri, nu puteți să deschideți un fișier AAB și să-l instalați direct pe un dispozitiv. Când încărcați unul în Magazinul Play, Google folosește pachetul pentru a genera fișiere APK diferite (nesemnate). Acele APK-uri trebuie apoi semnate înainte de a putea fi instalate.
În loc să ceară dezvoltatorului să semneze și să reîncarce acele APK-uri generate, Google gestionează singur semnarea. Magazinul Play fie folosește o cheie nouă pe care o creează, fie solicită dezvoltatorului cheia pe care o utilizează pentru a semna APK-uri. Cu oricare dintre opțiuni, Google se ocupă de semnarea publică pentru dezvoltator și oferă o încărcare cheie. Google folosește cheia de încărcare pentru verificarea internă și se asigură că App Bundle-ul (sau APK-ul în unele cazuri) pe care îl încarcă dezvoltator este cel potrivit.
Dacă o cheie de încărcare este compromisă sau pierdută, dezvoltatorii pot solicita una nouă, iar cheia de semnare folosită pentru a distribui aplicația rămâne neschimbată.
Există mult mai multe despre Semnarea aplicațiilor, dar acesta este ceea ce este relevant pentru acest articol. Dacă doriți, puteți citi mai multe despre App Bundle și App Signing on acest articol mediu de Wojtek Kaliciński.
Critică
În teorie și în practică, pachetele de aplicații sunt destul de grozave. Acestea reduc utilizarea datelor și dimensiunea instalării, toate fără ca utilizatorul să fie nevoit să facă nimic. Dar, din cauza modului în care este implementat, unii dezvoltatori și cercetători de securitate din ultimele câteva luni au exprimat îngrijorări. Înainte de a rezuma aceste preocupări, vreau să îmi iau un moment pentru a spune că majoritatea celor scrise mai jos sunt direct bazat pe o serie de articole de către dezvoltatorul Mark Murphy de CommonsWare. Ar trebui să verificați absolut articolele sale, deoarece oferă mai multe detalii și critici din perspectiva unui dezvoltator.
Securitate
În modelul clasic de distribuție, un dezvoltator păstrează cheia pe care o utilizează pentru a semna un APK privată. Nu este niciodată distribuită publicului și numai persoanele autorizate ar trebui să aibă acces la el. Acest lucru asigură că numai acele persoane pot genera un APK valid.
Dar dacă utilizați App Bundle în Magazinul Play, Google este cel care gestionează cheia care semnează APK-urile primite de utilizatori. The Mod implicit comportament pentru aplicațiile noi încărcate pe Google Play începând cu august 2021 este ca Google să își creeze propria cheie de distribuție pe care o păstrează privată de la dezvoltator.
Dezvoltatorii trimit aplicații noi va avea Google să își gestioneze cheia privată pentru ei în mod implicit, deși dezvoltatorii trimit actualizări la aplicațiile existente pot continua să folosească APK-urile sau pot trece la distribuția AAB prin generarea unei noi chei pe care Google să o utilizeze pentru noii utilizatori. Aplicații existente nu sunt necesare pentru a trece de la distribuția APK-urilor la Android App Bundle, deși această opțiune le este disponibilă dacă doresc. După câteva respingeri, Google chiar va face posibil pentru a încărca propria cheie privată cu care să se semneze Google, atât pentru aplicațiile noi, cât și pentru cele existente. Niciuna dintre aceste situații nu este ideală, deoarece orice ar fi, Google va avea acces la cheia dvs. privată dacă doriți utilizați Android App Bundle (și dezvoltatorii nu au de ales dacă doresc să trimită o nouă aplicație după august 2021!)
Deși suntem încrezători că Google ia securitatea foarte în serios, nu există nicio companie pe Pământ care să fie imună la încălcarea datelor. Dacă cheia pe care Google o folosește pentru a vă semna aplicația în vederea distribuirii se află într-una dintre aceste încălcări, atunci oricine poate semna o versiune a aplicației dvs. și poate face să pară că a fost semnată de dvs. Iar unii dezvoltatori și experți în securitate nu sunt mulțumiți de această posibilitate. Este o posibilitate foarte, foarte subțire, da, dar faptul că este o posibilitate îi sperie deloc pe unii din comunitatea infosec.
Dacă dezvoltatorii semnează APK-uri Android înseamnă că oricine poate verifica APK-urile de pe Google Play, nu este necesară încrederea oarbă. Este un design elegant care oferă securitate verificabilă. Pachetele de aplicații întorc asta și par structurate pentru a promova blocarea furnizorilor. Există multe abordări tehnice alternative care ar oferi APK-uri mici încă semnate de dezvoltatori, dar acestea nu ar prefera Play. De exemplu, toate variantele APK-ului ar putea fi generate și semnate de dezvoltator, apoi încărcate în orice magazin de aplicații.
Cu siguranță sunt argumente de făcut dacă este mai bine să lăsați stocarea securizată a cheilor private în mâinile Google sau dezvoltatorilor individuali. Dar acei dezvoltatori (probabil) nu folosesc de obicei un depozit central pentru cheile lor. Forțând dezvoltatorii să folosească Play App Signing, un atacator rău intenționat trebuie să încalce securitatea Google o singură dată pentru a recupera mii sau milioane de chei.
Pentru cât valorează, iată ce spune Google despre modul în care vă protejează cheia de semnare în infrastructura sa:
[blockquote author="Wojtek Kaliciński, Android Developer Advocate la Google"]Când utilizați Play App Signing, cheile dvs. sunt stocate în aceeași infrastructură pe care o folosește Google pentru a-și stoca propriile chei.
Accesul la chei este guvernat de ACL-uri stricte și de piste de audit pentru toate operațiunile.
Toate artefactele generate și semnate cu cheia dezvoltatorului vă sunt puse la dispoziție în Google Play Console pentru inspecție/atestare.
În plus, pentru a preveni pierderea cheii, facem copii de siguranță foarte frecvente ale stocării noastre principale. Aceste copii de siguranță sunt puternic criptate și testăm în mod regulat restaurarea din aceste copii de rezervă.
Dacă doriți să aflați despre infrastructura tehnică a Google, citiți Documente albe privind securitatea Google Cloud.[/blockquote]
La fel de grozav, toate sunetele, pierderea și furtul sunt încă posibile. Și pistele de audit ajută doar la prevenirea atacurilor viitoare; nu vor primi cheile sparte înapoi.
Potenţial pentru modificări neautorizate
O problemă majoră cu modul în care Google a configurat App Bundle-urile este potențialul de a adăuga modificări neautorizate la o aplicație. Procesul de extragere a APK-urilor dintr-un App Bundle implică în mod inerent modificări, deoarece Google trebuie să creeze manual fiecare APK. In timp ce Google a promis că nu injectează și nu va modifica cod, problema cu procesul App Bundle este că are puterea de a face acest lucru.
Iată câteva exemple de ceea ce o companie din poziția Google are puterea de a face:
Să presupunem că există o aplicație de mesagerie securizată pe care oamenii o folosesc pentru a comunica fără riscul supravegherii guvernamentale. Acesta ar putea fi un instrument incredibil de util pentru persoanele care protestează împotriva unui guvern autoritar sau chiar pentru persoanele care doresc doar să-și păstreze confidențialitatea. Guvernul respectiv, dorind capacitatea de a vedea ce spun utilizatorii aplicației, ar putea încerca să constrângă Google să adauge o ușă de supraveghere în codul aplicației.
Acest exemplu este puțin mai inofensiv, dar este și ceva care îi preocupă pe unii oameni. Să presupunem că există o aplicație care primește milioane de descărcări pe zi, dar nu conține reclame sau analize. Aceasta este o sursă de date uriașă, fără nicio modalitate de a accesa acele date. Google, fiind o companie de publicitate, ar putea dori să acceseze acele date.
În modelul APK clasic de distribuție a aplicațiilor, Google nu poate modifica aplicațiile fără a schimba semnătura. Dacă Google schimbă semnătura, în special într-o aplicație populară, oamenii vor observa deoarece actualizarea nu se va instala. Dar cu App Bundle și App Signing, Google și-ar putea injecta în tăcere propriul cod în aplicații înainte de a le distribui. Semnătura nu s-ar modifica deoarece Google ar deține cheia de semnare.
A fi clar, este incredibil de puțin probabil să se întâmple aceste exemple. Google tinde să facă pur și simplu retrage cu totul de pe piețele supărătoare, mai degrabă decât să se adapteze. Dar, deși este puțin probabil, este totuși posibil. Doar pentru că o companie promite că ceva nu se va întâmpla, nu garantează.
Transparența codului
Google, auzind aceste preocupări, în această săptămână a introdus o nouă caracteristică numită Transparența codului pentru pachetele de aplicații. Transparența codului permite unui dezvoltator să creeze în esență o a doua semnătură care este livrată cu aplicația utilizatorilor. Această semnătură suplimentară ar trebui creată dintr-o cheie privată separată la care are acces numai dezvoltatorul. Cu toate acestea, există unele limitări ale acestei metode.
Transparența codului acoperă numai codul. Acest lucru ar putea părea evident având în vedere numele, dar înseamnă, de asemenea, că nu permite utilizatorilor să verifice resurse, manifestul sau orice altceva care nu este un fișier DEX sau o bibliotecă nativă. În timp ce modificările rău intenționate ale fișierelor fără cod au de obicei mult mai puțin impact, este totuși o gaură în securitatea aplicației.
O altă problemă cu Transparența codului este că nu există o verificare inerentă. Pentru un, este o caracteristică opțională, așa că dezvoltatorii trebuie să-și amintească să îl includă pentru fiecare APK nou pe care îl încarcă. Momentan, trebuie făcut din linia de comandă și cu o versiune a bundletool care nu vine cu Android Studio. Chiar și atunci când un dezvoltator îl include, Android nu are încorporat niciun fel de verificare pentru a verifica dacă manifestul Transparența codului se potrivește cu codul din aplicație.
Este la latitudinea utilizatorului final să verifice singur, comparând manifestul cu o cheie publică pe care o poate furniza dezvoltatorul sau trimițând APK-ul dezvoltatorului pentru verificare.
În timp ce Transparența codului permite confirmarea că niciun cod dintr-o aplicație nu este modificat, nu include niciun fel de verificare pentru alte părți ale unei aplicații. De asemenea, nu există încredere inerentă în proces. Ai putea argumenta că, dacă nu ai încredere în Google, probabil că ești la îndemână sarcina de a verifica independent, dar de ce ar trebui să o faci?
Există și alte probleme cu caracteristica Transparența codului, cum ar fi Evidențiat de Mark Murphy de la CommonsWare. Recomand să citiți articolul său pentru o analiză mai aprofundată a caracteristicii.
Comoditatea și alegerea dezvoltatorului
Un al treilea (și ultim pentru acest articol) motiv pentru care unii dezvoltatori au probleme cu App Bundles-urile este confortul și alegerea reduse.
Dacă un dezvoltator creează o nouă aplicație în Magazinul Play după ce Google începe să solicite App Bundle și aleg opțiunea implicită de a lăsa Google să gestioneze cheia de semnare, nu vor avea niciodată acces la acea semnare cheie. Dacă același dezvoltator dorește apoi să distribuie acea aplicație într-un alt magazin de aplicații, va trebui să folosească propria cheie, care nu se va potrivi cu cea a Google.
Aceasta înseamnă că utilizatorii vor trebui fie să instaleze și să actualizeze din Google Play, fie din surse terțe. Dacă doresc să schimbe sursa, trebuie să dezinstaleze complet aplicația, potențial pierderea datelor și să o reinstaleze. agregatorilor APK le place APKMirror va trebui apoi să se ocupe de mai multe semnături oficiale pentru aceeași aplicație. (Din punct de vedere tehnic, trebuie deja să facă acest lucru, deoarece App Signing vă permite să creați o cheie nouă, mai sigură, pentru utilizatorii noi, dar va fi mai rău pentru ei și pentru alte site-uri când toată lumea are să o facă.)
Răspunsul Google la această problemă este să folosească Exploratorul App Bundle sau Exploratorul Artefact din Play Console pentru a descărca APK-urile rezultate din pachetul încărcat. La fel ca Transparența codului, aceasta nu este o soluție completă. APK-urile descărcate din Play Console vor fi împărțite pentru diferite profiluri de dispozitiv. Deși Play Console acceptă încărcarea mai multor APK-uri pentru o versiune a unei aplicații, multe alte canale de distribuție nu o fac.
Astfel, multe dintre beneficiile utilizării App Bundle-urilor dispar atunci când dezvoltatorii gestionează mai multe magazine, ceea ce face distribuția mai dificilă. Cu vești că Windows 11 este obținerea suportului pentru aplicații Android datorită Amazon Appstore-ului, unii cred că cerința App Bundles va descuraja dezvoltatorii să distribuie pe Amazon. Desigur, principala preocupare a Google este cu propriul magazin de aplicații, dar exact asta le-a aterizat în apă caldă cu concurenții conducându-i să facă schimbări mici, conciliante la modul în care magazinele de aplicații terță parte funcționează pe Android.
Câteva probleme legate de mai multe magazine sunt interconectivitatea aplicațiilor și testarea rapidă.
Să începem cu interconectivitatea aplicațiilor. Ați descărcat vreodată o aplicație care blochează funcții în spatele unui paywall? Aproape sigur. Unii dezvoltatori pun funcțiile în spatele unei achiziții în aplicație, dar alții pot alege să creeze o aplicație separată, plătită. Când acea aplicație suplimentară este instalată, funcțiile principale ale aplicației sunt deblocate.
Dar ce împiedică pe cineva să instaleze suplimentul dintr-o sursă pirat? Ei bine, există o mulțime de opțiuni pentru dezvoltatori, dar cel puțin una implică utilizarea permisiunilor protejate de semnătură. Să presupunem că aplicația principală declară o permisiune protejată de semnătură. Aplicația suplimentară declară apoi că dorește să folosească această permisiune. În mod ideal, aplicația suplimentară va avea, de asemenea, un fel de funcționalitate de verificare a licenței, care se conectează la internet pentru a se asigura că utilizatorul este legitim.
Dacă ambele aplicații au aceeași semnătură, Android va acorda permisiunea aplicației suplimentare, iar verificările de protecție împotriva pirateriei vor trece. Dacă aplicația suplimentară nu are semnătura potrivită, permisiunea nu va fi acordată și verificarea nu va reuși.
Cu modelul clasic de distribuție APK, un utilizator poate obține oricare dintre aplicațiile din orice sursă legitimă și poate termina cu ea. Cu modelul actual de App Bundle implicit, semnăturile aplicațiilor principale și suplimentare nu se vor potrivi. Google va crea o cheie unică pentru fiecare aplicație. Dezvoltatorul ar putea oricând să renunțe la permisiunea protejată prin semnătură și să folosească verificarea hash directă a semnăturii, dar aceasta este mult mai puțin sigură.
Și apoi sunt testele de foc rapid. Utilizatorii e-mail dezvoltatori tot timpul despre problemele din aplicațiile lor. Uneori, aceste probleme sunt remedieri simple: reproduceți problema, găsiți problema, remediați-o și încărcați o nouă versiune. Dar uneori nu sunt. Uneori, dezvoltatorii nu pot reproduce o problemă. Ei pot rezolva ceea ce cred că este problema, dar apoi utilizatorul trebuie să o testeze. Acum presupuneți că utilizatorul a instalat aplicația prin Google Play.
Cu modelul APK, un dezvoltator poate schimba un cod, poate construi și semna un nou APK și îl poate trimite utilizatorului pentru testare. Deoarece semnătura APK-ului de testare se potrivește cu cea instalată de utilizator, este un proces simplu de actualizat, testat și raportat. Cu App Bundle, acest lucru se destramă. Deoarece Google semnează APK-ul instalat inițial de utilizator, acesta nu se va potrivi cu semnătura APK-ului trimis de dezvoltator. Dacă această aplicație este publicată după termenul limită pentru App Bundles, dezvoltatorul nici măcar nu va avea acces la cheile pe care le folosește Google. Pentru a testa, utilizatorul ar trebui să dezinstaleze aplicația curentă înainte de a instala versiunea de testare.
Sunt o grămadă de probleme aici. În primul rând, există inconveniente, atât din partea dezvoltatorului, cât și a utilizatorului. A trebui să dezinstalezi aplicația doar pentru a testa o remediere nu este distractiv. Și dacă problema dispare? Au fost modificările făcute de dezvoltator sau pentru că utilizatorul a șters efectiv datele aplicației? Magazinul Play are Testare internă, care ar trebui să permită dezvoltatorilor să facă versiuni și distribuții rapide, dar necesită ca utilizatorul să dezinstaleze mai întâi versiunea de lansare. Nu prea remediază nimic.
În cazul în care toate acestea sună ca o grămadă de prostii ipotetice, iată un exemplu foarte real de dezvoltator care va avea aceste probleme dacă va lăsa Google să genereze o cheie privată pentru ei: João Dias. El este dezvoltatorul Tasker, împreună cu o mulțime de aplicații plugin, inclusiv suita AutoApps. Odată cu noua cerință privind pachetele de aplicații, ciclul de dezvoltare al lui João poate deveni mult mai complicat, cel puțin pentru aplicațiile noi. Trimiterea directă a versiunilor de testare va fi mai puțin convenabilă. Verificarea licențelor va fi mai puțin eficientă.
Acest lucru poate suna ca un caz de margine, dar nu se pare că João ar fi un dezvoltator mic și este probabil să nu fie singur. Există multe aplicații în Magazinul Play care se bazează pe verificarea semnăturii pentru a detecta utilizatorii nelegitimi.
Desigur, cu noua opțiune pentru dezvoltatori de a-și încărca propriile chei de semnare pe Google, aceste probleme sunt cel puțin oarecum atenuate. Dar dezvoltatorii trebuie să se înscrie pentru a activa opțiunea pentru fiecare aplicație. În caz contrar, interconexiunile vor eșua, iar asistența rapidă va necesita încărcarea unui pachet pe Google și așteptarea ca APK-urile să fie generate, înainte de a-l trimite utilizatorului pe cel corect. În plus, înseamnă în continuare că trebuie să-și partajeze cheia privată, ceea ce ne readuce la preocupările despre care am discutat mai devreme.
Soluții
Aceasta este o problemă veche, având în vedere că cerințele App Bundle au fost făcute publice cu luni în urmă, așa că au fost destul de multe soluții propuse între timp.
O soluție este să evitați necesitatea semnării aplicației Play. În loc să genereze un App Bundle pe care Google îl prelucrează apoi în APK-uri și semne, acea procesare ar putea fi efectuată de Android Studio. Apoi, dezvoltatorii pot încărca un fișier ZIP plin de APK-uri semnate local pentru fiecare configurație pe care Google ar fi generat-o.
Cu această soluție, Google nu ar avea deloc nevoie de acces la cheile dezvoltatorilor. Procesul ar fi foarte asemănător cu modelul clasic de distribuție APK, dar ar implica mai multe APK-uri mai mici, în loc de doar unul.
O altă soluție este pur și simplu să nu necesită utilizarea App Bundle-urilor și să le permită dezvoltatorilor să încarce APK-uri semnate local. În timp ce App Bund-urile pot fi o experiență mai bună pentru utilizator în multe cazuri, unele aplicații nu beneficiază de fapt de a fi împărțite în funcție de configurație, cu dimensiune minimă reducere.
Dacă Google a implementat ambele soluții, atunci un dezvoltator care dorește să folosească App Bundle nu va mai avea la îndemână peste semnarea la Google, iar un dezvoltator a cărui aplicație nu va beneficia prea mult de pe urma formatului nu va trebui să o folosească la toate.
Răspunsurile Google
Autosemnare
Când au fost întrebați pentru prima dată despre permiterea dezvoltatorilor să se ocupe de semnarea pentru App Bundle, răspunsul Google a fost foarte lipsit de angajare:
[blockquote author=""]Așadar, am vorbit pe scurt despre cerința de anul viitor ca noile aplicații să utilizeze pachetele de aplicații și un lucru care vine cu asta este că, prin extensie, vom avea nevoie de semnarea aplicațiilor Play. Așadar, dezvoltatorii vor trebui fie să genereze cheia de semnare a aplicației pe Play, fie să își încarce propria cheie în Play... deoarece aceasta este o condiție prealabilă pentru pachetele de aplicații. Am auzit de la dezvoltatori că unii dintre ei pur și simplu nu vor să o facă. Nu vor să aibă cheile gestionate de Play. Și în prezent acest lucru nu este posibil dacă doriți să utilizați pachetele de aplicații.
Dar, am auzit acel feedback și... Nu pot vorbi despre nimic acum, nu avem nimic de anunțat, dar căutăm cum am putea atenua unele dintre aceste preocupări. Nu trebuie neapărat să vă permită să vă păstrați propria cheie în timp ce încărcați pachete. Căutăm diferite opțiuni. Pur și simplu nu avem o soluție de anunțat acum. Dar, mai avem aproximativ un an până la cerință, așa că sper cu adevărat că vom avea un răspuns pentru dezvoltatori pentru acest lucru.[/blockquote]
Asta a fost la sfârșitul lunii noiembrie a anului trecut și nu pare să se fi întâmplat nimic. Cu doar câteva luni rămase înainte de Cerința privind pachetele de aplicații intră în vigoare, încă nu există o modalitate ca dezvoltatorii să se ocupe de semnarea propriilor aplicații. În timp ce Google a făcut acum posibil încărcați propria ta cheie atât pentru aplicațiile noi, cât și pentru cele existente, acest lucru ia în continuare partea de semnare din mâinile dezvoltatorului.
Schimbări de cod
În timp ce Google a promis în mod expres că Magazinul Play nu va modifica codul aplicației, o promisiune nu este o garanție. Cu App Bundle și App Signing, nu există nicio limitare tehnică pe care o cunoaștem pentru a împiedica Google să modifice aplicațiile încărcate înainte de distribuire.
Google a introdus Transparența codului ca o caracteristică opțională și, deși acest lucru ajută oarecum, are o parte echitabilă de probleme, așa cum am discutat mai devreme.
Pachete autofabricate
Când Google a fost întrebat despre posibilitatea dezvoltatorilor să-și creeze propriile „pachete” de aplicații (zip-uri care conțin APK-uri împărțite), răspunsul a fost practic „nu vom face asta”:
Probabil că nu așa cum este descris în întrebare, deoarece acest lucru ar face procesul de publicare și mai dificil pentru dezvoltatori și, de fapt, vrem să-l facem mai simplu și mai sigur. Cu toate acestea, din nou, am auzit acest feedback și vom analiza opțiunile pentru a face acest lucru posibil, însă probabil nu în modul descris aici.
Interesant este că justificarea Google pare să fie că ar face publicarea mai complicată. Cu toate acestea, Google ar putea să automatizeze procesul ca parte a dialogului de generare a APK-ului în Android Studio. În plus, dacă aplicația în cauză este distribuită în mai multe magazine, ar face de fapt procesul de publicare mai simplu, deoarece dezvoltatorii nu ar trebui să gestioneze mai multe chei de semnare și reclamații de la utilizatorii.
Și odată cu introducerea Code Transparency, se pare că complicația nu este chiar o problemă până la urmă. Transparența codului, cel puțin deocamdată, necesită ca dezvoltatorul să folosească un instrument de linie de comandă și ca utilizatorii să verifice în mod explicit validitatea aplicației pentru care sunt servite. Acest lucru este mai complicat decât un proces de auto-creare pachete și nu este clar de ce aceasta este soluția pe care o preferă Google.
Mergand inainte
App Bundle-urile vor fi formatul de distribuție necesar pentru aplicațiile noi trimise pe Google Play începând cu 1 august. În timp ce Google a abordat cel puțin oarecum majoritatea problemelor ridicate de dezvoltatori și experți în securitate, răspunsurile lasă mult de dorit. Există multe beneficii evidente ale App Bundle-urilor ca format de distribuție de generație următoare, dar vor exista întotdeauna preocupări persistente cu privire la acordarea unui control parțial sau total asupra semnării aplicațiilor către Google.
Răspunsurile și eforturile Google sunt cu siguranță apreciate, dar unii, precum Mark Murphy, consideră că nu au mers suficient de departe. Cu soluții precum pachetele realizate de sine stătătoare, nefiind implementate și termenul limită pentru pachetele de aplicații Android fiind solicitat rapid se apropie, nu se pare că dezvoltatorii de pe Google Play vor putea păstra controlul deplin asupra aplicațiilor lor pentru mult timp mai lung.
Vom vorbi despre implicațiile cerinței Android App Bundle într-un spațiu Twitter mai târziu în această după-amiază, așa că alăturați-vă nouă!