Conform unui set de comite din AOSP, Google poate începe să restricționeze accesul la API-uri nedocumentate sau ascunse în Android P. Multe aplicații de marcă folosesc API-uri ascunse pentru a spori funcționalitatea, astfel încât efectul poate fi larg răspândit.
Actualizare 28.02.18: Google a publicat astăzi o postare pe blog care confirmă modificările. Mai multe detalii la finalul articolului.
În timp ce unii pasionați de Android sunt speculând după ce desert va fi numită următoarea versiune de Android, există câteva evoluții interesante în spatele scenei. Am observat o câteva demne de remarcat funcții viitoare în Android P, dar o descoperire mai recentă în Android Open Source Project (AOSP) s-a dovedit mult mai interesantă. Conform acestor comiteri recente, aplicațiile pot fi restricționate de la accesarea API-urilor care sunt nedocumentate în SDK-ul Android (cum ar fi API-urile marcate de atributul javadoc @hide).
De ce contează asta
Android Software Development Kit (SDK) oferă dezvoltatorilor biblioteci API și instrumente de care au nevoie pentru a testa și a crea noi aplicații Android. Odată cu fiecare nouă lansare de Android vine o serie întreagă de noi API-uri care sunt disponibile dezvoltatorilor prin SDK-ul Android. Ce API-uri sunt disponibile pentru o aplicație depind de ce versiune SDK de compilare setată de dezvoltator. De aceea, Google
noi cerințe pentru Magazinul Play sunt atât de semnificative – va forța aplicațiile să se actualizeze și să migreze la utilizarea API-urilor mai noi.găzduiește Google pagini de documentare pentru fiecare clasă și toate metodele sale care sunt disponibile în fiecare nivel API. Acestea sunt setul de API-uri documentate care sunt disponibile în SDK-ul oficial Android. Puteți răsfoi cu ușurință lista de cursuri folosind o aplicație Android, cum ar fi aplicația Android SDK Search recent lansată de Android Engineer Jake Wharton.
Pret: Gratuit.
4.1.
Cu toate acestea, nu toate API-urile care sunt disponibile în fiecare lansare Android sunt documentate de Google sau disponibile în SDK-ul oficial Android. Există adesea API-uri utile care sunt nedocumentat, dar sunt totuși foarte utile. Nu este recomandat ca dezvoltatorii să-și construiască aplicațiile folosind API-uri nedocumentate sau ascunse, dar mulți o fac pentru că pur și simplu nu există alternativă dacă doresc să ofere o anumită caracteristică. Dezvoltatorii care folosesc API-uri ascunse sau nedocumentate se pot pune, de asemenea, la un avantaj competitiv, deoarece pot oferi funcții pe care concurenții lor, care se țin de API-urile oferite de Android SDK—nu se poate.
Deși nu pot oferi o listă de aplicații care utilizează API-uri nedocumentate (dezvoltatorii probabil nu distribuie pe care le folosesc pentru că le-ar oferi concurenților lor un avans), lista este probabil mai degrabă mare. Astfel, aș concluziona că interzicerea accesului la API-urile ascunse ar fi semnificativă. Mark Murphy, fondatorul Comunware, este de acord:
Sunt de acord cu evaluarea conform căreia interzicerea în bloc a accesului la articolele adnotate @hide va fi o mare problemă, dacă acest lucru se va întâmpla. Sperăm că puține aplicații accesează aceste elemente ca parte a funcționalității cheie. Cu toate acestea, bănuiesc că multe aplicații de marcă le folosesc ocazional, direct sau printr-o bibliotecă.
Ce se întâmplă în Android P?
Aceste modificări viitoare au fost observate pentru prima dată de către dezvoltatorul principal recunoscut XDA rovo89, dezvoltatorul Cadrul Xposed. Mi-a subliniat două angajamente, una dintre ele care a fost comasate, care introduce un nou instrument de compilare numit „hiddenapi”. Acest instrument modifică steaguri de acces ale tuturor membrilor clasei dintr-un fișier DEX dacă semnăturile lor apar pe o listă gri sau pe o listă neagră de intrare și, dacă da, metodele marcate vor fi tratate ca API-uri interne cu restricții acces. Celălalt commit descrie modul în care funcționează lista neagră API; împiedică accesul la clasa de boot metode și câmpuri marcate de „hiddenapi” menționat mai sus, pe care dezvoltatorii le pot accesa prin legătură statică, reflectare și JNI.
Potrivit rovo89, rezultatul final al acestor două modificări în Android P este următorul:
Dacă aceste commit-uri sunt îmbinate, ar însemna că aplicațiile nu mai pot utiliza/accesa API-uri ascunse, adică clase, metode și câmpuri care sunt adnotate cu @hide în AOSP și, prin urmare, nu fac parte din SDK oficial. Aceasta nu ar fi o problemă pentru modulele Xposed, deoarece aș putea anula cu ușurință acele comiteri sau aș permite modulelor să accesați aceste API-uri. Dar există multe aplicații care profită de API-urile ascunse, iar acestea ar eșua în viitor.
Într-adevăr, alte angajamente arată că acesta poate fi ceea ce Google plănuiește. Acest comite afirmă următoarele:
Deși această comitere specială nu a fost îmbinată, deoarece a fost abandonată în favoarea a 3 comiteri mai mici, mesajul de comitere descrie scopul acestor modificări. Un alt set de comite arată că Google va sugera alternative dezvoltatorilor care doresc să utilizeze API-uri non-publice:
Cu toate acestea, adesea nu există alternative la anumite API-uri ascunse. Noi cei de la XDA putem vorbi din experiență aici ca din păcate, această schimbare poate semna sfârşitul unor aplicaţii inovatoare sau poate necesita unele aplicaţii de renume pentru a-şi reduce funcţionalitate. Această schimbare viitoare pare similară în spirit cu cea recentă represiune asupra serviciilor de accesibilitate (asta a fost din fericire oprit întrucât Google a evaluat utilizări inovatoare). În timp ce majoritatea aplicațiilor care utilizează API-uri nedocumentate fac acest lucru din motive benigne, pot exista unele aplicații care le-au folosit greșit în scopuri nefaste.
Din această cauză, Google poate bloca accesul la toate API-urile ascunse din Android P pentru a proteja utilizatorii de puținii care le abuzează. Este greu de spus cât de mult impact poate avea acest lucru asupra utilizatorilor, dar dacă ești dezvoltator luând în considerare căutarea prin AOSP pentru a găsi o utilizare inovatoare a unui API ascuns, atunci poate doriți reconsidera.
Actualizare: Google confirmă
Într-o postare pe blog publicat astăzi, 28 februarie, Google a confirmat aceste modificări. Invocând riscurile de blocare pentru utilizatori și, ulterior, forțând dezvoltatorii să lanseze remedieri de urgență, Google afirmă că compania a trecut treptat spre descurajarea dezvoltatorilor de a accesa non-SDK interfețe. Începând cu Android P, restricțiile se vor extinde pentru a acoperi interfețele în limbajul Java ale SDK-ului.
Compania afirmă că „unele metode și câmpuri non-SDK vor fi restricționate”, deși nu a precizat care dintre ele ar fi restricționate. Inițial restricția se va concentra pe interfețe care sunt rar utilizate, iar pentru o perioadă compania va permite dezvoltatorii să continue să folosească metode și câmpuri non-SDK în care tranziția la o metodă SDK este din punct de vedere tehnic provocator. Cu toate acestea, în cele din urmă restricțiile se vor extinde, astfel încât dezvoltatorii de aplicații care utilizează metode non-SDK ar trebui să tranzițieze cât mai curând posibil, în pregătirea pentru Android P. În ceea ce privește metodele fără o alternativă SDK, Google le solicită dezvoltatorilor să posteze pe lor bug tracker cu mai multe informatii.
Următoarea previzualizare pentru dezvoltatori, care aparent va sosi în curând, le va permite dezvoltatorilor să testeze aplicațiile existente pe lista neagră sau pe lista gri înainte de lansarea finală.