Cerințele Google Play privind calitatea tehnică asigură experiențe de înaltă calitate pentru utilizatorii aplicațiilor tale de pe Google Play, ca parte a celor patru piloni ai calității aplicațiilor pentru Android.
Cerințele privind calitatea tehnică de pe Google Play sunt organizate în două categorii:
- cerințe actuale: cerințe aplicate activ în momentul de față. Respectarea acestor standarde este esențială pentru a menține stabilitatea, performanța și vizibilitatea aplicației pe Google Play.
- cerințe viitoare: noi standarde anunțate în prealabil. Deși acestea nu sunt încă obligatorii, îți recomandăm să folosești perioada de tranziție pentru a-ți evalua aplicația, a integra instrumentele și API-urile recomandate și a îndeplini cerințele înainte de începerea aplicării.
Cerințe viitoare
După cum am anunțat pe 26 august 2026, urmează cerințe tehnice privind calitatea pentru aplicațiile și jocurile publicate pe Google Play. Acest articol din Centrul de ajutor oferă mai multe detalii despre pragurile tehnice și are scopul de a te ajuta să înțelegi și să te pregătești pentru noile cerințe înainte ca acestea să intre în vigoare.
Utilizarea redusă a memoriei
Începând din februarie 2027, aplicațiile și jocurile de pe Play vor trebui să respecte noi praguri pentru performanța slabă. Vezi mai jos detalii specifice.
Optimizarea codului
Din februarie 2027, aplicațiile și jocurile de pe Play vor trebui să respecte pragurile de optimizare. Vezi mai jos detalii specifice.
Restabilirea conectării fără atingere
Din aprilie 2027, aplicațiile de pe Play vor trebui să accepte restabilirea fără atingere a datelor de conectare. Vezi mai jos detalii specifice.
Utilizarea redusă a memoriei
Google Play a definit praguri pentru performanța slabă pentru detaliile de funcționare de bază ale aplicației. Utilizarea memoriei este introdusă ca nou detaliu de funcționare de bază, cu două valori:
- Utilizarea memoriei (RSS anonim + spațiul de înlocuire),
- Utilizarea memoriei bitmap.
La fel ca valorile existente în Detaliile de funcționare Android cu praguri pentru performanța slabă, Play folosește datele din ultimele 28 de zile pentru a evalua calitatea aplicației.
Aceste valori sunt disponibile în secțiunea Memorie din Prezentarea generală a detaliilor de funcționare Android, precum și în Google Play Developer Reporting API.
Valorile măsoară memoria folosită de aplicație pe durata ciclului de activitate al aplicației, după ce este încărcată din spațiul de stocare și rulează, din prim-plan în fundal.
Valorile sunt eșantionate de pe dispozitivele înscrise ale utilizatorilor, anonimizate și agregate. În Play Console, poți vedea diferite percentile pentru fiecare, inclusiv percentila 90, care este folosită pentru a evalua performanța aplicației în raport cu pragurile pentru performanța slabă. Valoarea percentilei 90 înseamnă că 10 % dintre exemplele adunate în decurs de o zi au avut un număr mai mare. De exemplu, o percentilă 90 de 1,7 GB indică faptul că 90 % dintre eșantioanele colectate au avut o valoare mai mică de 1,7 GB, iar 10 % dintre eșantioanele colectate au avut o valoare mai mare de 1,7 GB.
Această cerință se aplică numai factorilor de formă mobil și tabletă.
Utilizarea memoriei
Dimensiunea setului rezident anonim (Anon RSS) reprezintă memoria alocată direct de aplicație (cum ar fi memoria heap Java / Kotlin, alocările de memorie nativă și mapările de memorie anonime) care nu poate fi paginată pe disc fără swap. Schimbă conturile pentru memoria comprimată sau paginată în zRAM.
Pragurile sunt adaptate categoriei aplicației (Aplicații vs. Jocuri) și nivelului de memorie RAM a dispozitivului, pentru a reflecta diversele limitări de hardware. Începând din februarie 2027, aplicațiile și jocurile de pe Play vor trebui să respecte următoarele praguri pentru a rămâne conforme:
Aplicații
| Starea aplicației | Prim-plan | Servicii percepute de utilizatori | Fundal | În memoria cache |
| Memorie RAM fizică | Percentila 90 | Percentila 90 | Percentila 90 | Percentila 90 |
|
0 – 4 GB (Memorie totală de 0 MB – 3.200 MB) |
- | – | – | - |
|
4 GB (Memorie totală de 3.200 MB – 4.800 MB) |
2 GB | 1 GB | 1 GB | - |
|
6 GB (Memorie totală de 4.800 MB – 6.800 MB) |
2,25 GB | 1,25 GB | 1,25 GB | - |
|
8 GB (Memorie totală de 6.800 MB – 9.216 MB) |
2,25 GB | 1,5 GB | 1,5 GB | - |
|
12 GB (Memorie totală de 9.216 MB – 14.336 MB) |
3,25 GB | 1,75 GB | 1,75 GB | - |
|
16 GB (Memorie totală de 14.336 MB – 18.432 MB) |
4,25 GB | 2 GB | 2 GB | - |
|
16 GB + (Peste 18.432 MB de memorie totală) |
- | – | – | - |
Notă: fiecare interval de nivel RAM include valoarea cea mai mică. Memoria totală poate fi mai mică decât memoria RAM fizică promovată a unui dispozitiv.
Jocuri
| Starea aplicației | Prim-plan | Servicii percepute de utilizatori | Fundal | În memoria cache |
| Memorie RAM fizică | Percentila 90 | Percentila 90 | Percentila 90 | Percentila 90 |
|
0 – 4 GB (Memorie totală de 0 MB – 3.200 MB) |
- | – | – | - |
|
4 GB (3200 MB – 4800 MB memorie totală) |
2,25 GB | 2,0 GB | 2,0 GB | - |
|
6 GB (Memorie totală de 4.800 MB – 6.800 MB) |
2,75 GB | 2,5 GB | 2,5 GB | - |
|
8 GB (Memorie totală de 6.800 MB – 9.216 MB) |
3,5 GB | 2,75 GB | 2,75 GB | - |
|
12 GB (Memorie totală de 9.216 MB – 14.336 MB) |
4 GB | 3,2 GB | 3,2 GB | - |
|
16 GB (Memorie totală de 14.336 MB – 18.432 MB) |
5 GB | 3,5 GB | 3,5 GB | - |
|
16 GB + (Peste 18.432 MB de memorie totală) |
- | – | – | - |
Notă: fiecare interval de nivel RAM include valoarea cea mai mică. Memoria totală poate fi mai mică decât memoria RAM fizică promovată a unui dispozitiv.
Utilizarea memoriei bitmap
Păstrarea structurilor bitmap pe perioade lungi în alte stări ale aplicației decât Prim-plan poate consuma prea multă memorie. Nu este posibilă redarea structurilor bitmap decât dacă interfața de utilizare este vizibilă. De obicei, nu ar trebui să păstrezi structurile bitmap pe perioade lungi în aceste stări, dar aplicația poate fi eșantionată la scurt timp după o modificare a stării în care răspunzi activ la onTrimMemory și eliberezi memoria păstrată pentru structuri bitmap, prin urmare aceste praguri sunt mai mari decât zero pentru a ține cont de acest aspect.
| Starea aplicației | Percentila 90 |
| Prim-plan | |
| Servicii percepute de utilizatori | > 200 MB |
| Fundal | > 200 MB |
| În memoria cache | > 400 MB |
Optimizarea codului DEX
Începând din februarie 2027, aplicațiile și jocurile de pe Google Play vor trebui să îndeplinească cerințele minime de optimizare. Va trebui să obții o optimizare, o obscurizare și o restrângere de minimum 25 % pentru toate încărcările de aplicații în Play Console. Înțelegem că unele aplicații sau jocuri nu folosesc intens cod DEX, prin urmare această cerință va fi aplicată numai dacă ai dimensiuni DEX non-neglijabile. Poți vedea dimensiunea DEX, precum și procentele de optimizare pentru fiecare app bundle pe care îl încarci în Exploratorul app bundle din Play Console.
Această cerință se aplică pentru toți factorii de formă.
| Jocuri | Aplicații | |||
| Optimizarea codului | Jocuri cu cod DEX > 50 MB | Aplicații cu cod DEX > 10 MB | ||
| Obscurizare | 25 % | 25 % | ||
| Optimizare | 25 % | 25 % | ||
| Restrângere | 25 % | 25 % | ||
Poți folosi orice instrument, cum ar fi R8 sau alt instrument de restrângere a aplicațiilor, pentru a atinge pragul minim de 25 %.
Poți folosi R8 Configuration Analyzer pentru a obține mai multe informații și pentru a-ți optimiza performanța. Reține că, dacă publici prin intermediul pipeline-urilor CI / CD sau într-un mediu de companie, este posibil ca versiunile locale să nu corespundă perfect versiunii încărcate în Play Console pentru distribuire către utilizatori, prin urmare, te poți aștepta la câteva diferențe minore.
Restabilirea conectării fără atingere
Începând din aprilie 2027, aplicațiile care acceptă conectarea utilizatorilor (opțională sau obligatorie) trebuie să accepte restabilirea conectării fără atingere atunci când un utilizator trece de la dispozitivul Android anterior la unul nou și alege să-și restabilească datele dintr-un transfer de pe un dispozitiv pe altul sau dintr-un backup în cloud. Conectările manuale în timpul configurării dispozitivului nu numai că provoacă probleme la integrare și reduc fidelizarea utilizatorilor, ci expun în mod activ aplicațiile la vulnerabilități de securitate critice, cum ar fi phishingul și furtul datelor de conectare în timpul configurării. API-ul Android Restore Credentials este metoda principală de a rezolva aceste probleme și de a îndeplini această cerință și este disponibil începând cu Android 9.
Excepții și arie de acoperire:
- aplicațiile care se integrează cu Block Store pe sau înainte de 30 septembrie 2026 pentru a restabili starea de conectare a unui utilizator sunt considerate conforme cu această cerință;
- aplicațiile de gestionare a dispozitivelor permanent private și de întreprinderi nu intră în aria de acoperire a acestei cerințe;
- aplicațiile care se supun unor cerințe de reglementare sau de conformitate stricte care influențează modul în care rulează funcția de conectare (cum ar fi serviciile financiare sau asistența medicală) pot fi eligibile pentru o excepție. Dezvoltatorii trebuie să trimită o solicitare de scutire de la această cerință prin Play Console înainte de data aplicării.
- momentan, jocurile nu fac obiectul acestei cerințe. Dezvoltatorii se pot aștepta la orientări specifice și soluții personalizate pentru situații de folosire complexe a autentificării în jocuri, care vor fi disponibile în 2027. Pentru jocurile care acceptă un singur cont de utilizator, îți recomandăm insistent să folosești API-ul Restore Credentials pentru a accepta conectarea fără atingere.
Mai multe detalii despre cerință și excepții vor fi publicate în lunile următoare.
Integrare și testare
Testează integrarea pentru a te asigura că utilizatorii au o experiență fluidă și că îndeplinești această cerință. Articolul Abilitatea AI pentru Restore Credentials publicat recent te poate ajuta să faci integrarea mai ușor.
Factori de formă și versiuni Android care fac obiectul
Această cerință se aplică numai factorilor de formă mobil / tabletă. API-ul Restore Credentials nu este momentan acceptat pentru alți factori de formă. Restore Credentials este disponibil pe Android 9 și versiunile ulterioare.
Întrebări frecvente despre cerințele viitoare
Cerințe privind memoria
De ce introduce Google măsura de aplicare pentru valorile memoriei?
Din cauza creșterii costurilor cu memoria RAM, este iminentă o criză de memorie la nivel de ecosistem. Folosirea ineficientă a memoriei, cum ar fi o singură aplicație cu o eroare necontrolată privind memoria care consumă cea mai mare parte a memoriei dispozitivului, face ca dispozitivul să redea sacadat și să închidă alte aplicații care funcționează corect în fundal. Android a anunțat limite stricte de memorie, iar Play vrea să se asigure că aplicația ta le respectă și să minimizeze șansele ca dispozitivul să fie nevoit să închidă aplicația.
Cum pot reduce utilizarea memoriei?
Respectă recomandările pentru aplicații și jocuri. Printre strategiile cheie se numără eliberarea resurselor în onTrimMemory() (inclusiv folosirea motorului de jocuri în acest scop), evitarea erorilor statice privind memoria prin folosirea componentelor care țin cont de ciclul de activitate, crearea de profiluri ale alocărilor și datelor privind memoria heap folosind Perfetto și reducerea la minimum a activităților din fundal de lungă durată.
Cum pot reduce alocările de structuri bitmap?
Fă downsampling și decodează imaginile pentru a se potrivi cu dimensiunile exacte ale afișării, folosește biblioteci moderne de încărcare a imaginilor (cum ar fi Coil sau Glide) configurate cu memorii cache care țin cont de memorie, eliberează structurile bitmap nefolosite din memorie când interfața de utilizare este ascunsă (prin TRIM_MEMORY_UI_HIDDEN în onTrimMemory) și evită să păstrezi referințe statice la structuri bitmap sau afișări.
Trebuie să folosesc R8 pentru optimizarea codului?
Deși îți recomandăm să folosești R8 pentru optimizările și statisticile avansate, sunt disponibile și alte instrumente de optimizare care pot fi folosite pentru a îndeplini această cerință.
De ce diferă cerințele între aplicații și jocuri?
Jocurile au diferite modele de utilizare a memoriei pentru a oferi o experiență de joc fluidă, în principal în prim-plan. Acestea se bazează adesea pe motoare de jocuri native, care au constrângeri tehnice diferite de cele ale aplicațiilor. Cerințele pentru jocuri sunt adaptate situației de folosire.
Cum face Play distincția între o aplicație și un joc?
În funcție de categoria pe care o poți configura în Setările magazinului din Play Console, care influențează secțiunea din Magazinul Play în care apare aplicația. Reține că schimbarea categoriei aplicației cu una care nu reflectă corect funcționalitatea de bază a acesteia, în încercarea de a te califica pentru alte praguri tehnice, reprezintă o încălcare a Politicii privind metadatele pentru înregistrarea în magazin.
Cum se intersectează aceste cerințe cu programul Apps Experience și programul Level Up?
După ce intră în vigoare măsura de aplicare pentru aceste praguri de memorie, aplicațiile și jocurile trebuie să respecte toate pragurile de memorie pentru a se califica sau a-și menține eligibilitatea pentru AEP și Level Up.
Limitele de memorie Android se aplică pe Android 17 sau versiunile ulterioare. Cerințele Play sunt create numai pentru A17 sau versiunile ulterioare?
Nu, Google Play evaluează toate versiunile aplicației pentru care sunt disponibile date. Acestea încep cu Android 13 sau o versiune ulterioară pentru utilizarea memoriei (Anon RSS + spațiu de înlocuire) și utilizarea memoriei bitmap.
De ce există praguri diferite pentru Anon RSS + spațiu de înlocuire și fiecare nivel de memorie RAM?
Împărțirea în funcție de nivelul de RAM confirmă faptul că dispozitivele diferite au niveluri de toleranță diferite pentru utilizarea excesivă a memoriei. Ce este performant pe un dispozitiv de 16 GB poate să nu fie la fel de performant pe un dispozitiv de 4 GB. Trebuie să te asiguri că aplicația nu folosește prea multă memorie la toate nivelurile de RAM.
Ce factori de formă sunt vizați de cerințele privind memoria?
Pentru valorile Utilizarea memoriei (RSS anonim + spațiul de înlocuire) și Utilizarea memoriei bitmap, factorii de formă mobil și tabletă sunt în aria de acoperire.
Ce instrumente sunt disponibile pentru a înțelege mai bine utilizarea memoriei?
-
Poți începe să îmbunătățești memoria pentru aplicații sau jocuri folosind instrucțiunile privind memoria.
-
Google Play Console (Detalii de funcționare Android): monitorizează valorile mediei mobile P90 pe 28 de zile pentru utilizarea memoriei (Anon RSS + spațiu de înlocuire) și utilizarea memoriei bitmap, care pot fi filtrate după Starea aplicației (Prim-plan, Serviciu perceput de utilizator, Fundal, În memoria cache), Nivelul RAM al dispozitivului (de exemplu, 4 – 6 GB), versiunea Android și versiunea aplicației.
-
Google Play Developer Reporting API: interoghează automat valorile pentru a automatiza rapoartele, a identifica regresii ale performanței și a integra datele despre detaliile de funcționare în tablourile de bord interne.
-
Profilerul de memorie și datele privind memoria heap din Android Studio: inspectează alocările în timp real din memoria heap Java / Kotlin, memoria nativă și memoria grafică. Înregistrează și analizează datele privind memoria heap (.
hprof) pentru a detecta erorile privind memoria, activitățile neeliberate, structurile bitmap dublură și căile de păstrare. -
Perfetto și Urmărirea sistemului: folosește Perfetto (
heapprofd) pentru eșantionarea cu supraîncărcare redusă a alocărilor native și Java, pentru a identifica stivele de apeluri care cauzează creșteri ale utilizării memoriei. Urmărirea sistemului ajută la urmărirea utilizării memoriei în timpul tranzițiilor din ciclul de activitate și la corelarea cu evenimentele de oprire din cauza memoriei insuficiente (lmkd). Sunt disponibile și abilități de analiză cu AI (cum ar fi abilitățile Perfetto AI) pentru a automatiza analiza urmăririi și a datelor privind memoria heap. -
Instrumente de diagnosticare pe dispozitiv: folosește
adb shell dumpsys meminfo <package_name>pentru o detaliere live pentru PSS, Private Dirty (Anon RSS), Swap Dirty (zRAM) și Bitmaps sau instrumentulComponentCallbacks2.onTrimMemory()pentru telemetrie personalizată a clientului.
De ce există o limită minimă a dimensiunii DEX pentru optimizarea codului?
Deși recomandăm întotdeauna optimizarea codului pentru numeroasele beneficii de performanță, echilibrăm efortul necesar pentru a recrea și a optimiza o aplicație sau un joc cu beneficiile pentru utilizatori. Dimensiunile mici ale fișierelor DEX (sub 10 MB pentru aplicații și sub 50 MB pentru jocuri) au un impact limitat asupra memoriei utilizate de dispozitive, prin urmare nu impunem optimizarea codului în acest caz.
Restabilirea conectării fără atingere
Cheia de restabilire persistă dacă o aplicație este dezinstalată și reinstalată pe același dispozitiv?
Nu. Cheia de restabilire este ștearsă automat când o aplicație este dezinstalată.
Această cerință se aplică tuturor factorilor de formă?
Nu, cerința privind restabilirea fără atingere a datelor de conectare se aplică numai factorilor de formă mobil și tabletă.
Această cerință se aplică dacă un utilizator nu este conectat sau pentru aplicațiile fără conturi de utilizator?
Nu. Cerința este concepută pentru a menține o stare de conectare activă în timpul tranzițiilor între dispozitive.
-
Aplicații fără conectarea utilizatorului: aplicațiile care nu oferă conturi de utilizator sau funcții de conectare nu sunt afectate.
-
Utilizatori deconectați sau invitați: dacă un utilizator s-a deconectat, a folosit modul pentru invitați sau s-a deconectat înainte să schimbe dispozitivul, aplicația trebuie să se lanseze în aceeași stare neautentificată pe noul dispozitiv.
Restore Credentials funcționează cu orice metodă de autentificare?
Da, API-ul Restore Credentials este conceput să funcționeze cu orice metodă de autentificare, permițând aplicațiilor să stocheze o cheie de restabilire.
Restore Credentials gestionează ariile de acoperire pentru autorizare sau verificarea suplimentară (de exemplu, MFA)?
-
Nu. API-ul Restore Credentials este conceput exclusiv pentru autentificare (restabilirea identității și a sesiunii utilizatorului). Nu gestionează solicitările de autorizare secundare, cum ar fi acordarea permisiunilor OAuth sau provocările cu mai mulți factori.
-
Recomandăm o abordare în doi pași:
-
restabilește identitatea: folosește Restore Credentials pentru a restabili silențios starea de conectare principală a utilizatorului la prima lansare pe noul dispozitiv;
-
autorizează în context: solicită permisiuni pentru anumite resurse (de exemplu, accesul la Google Drive) la momentul oportun, când utilizatorul accesează funcțiile care le necesită. Dacă este necesar, poți solicita și autentificarea suplimentară (de exemplu, MFA).
-
Cum aflu dacă integrarea mea îndeplinește cerința?
Restabilirea conectării utilizatorului se stabilește prin preluarea cheii de restabilire. Aplicațiile pe care le identificăm ca neîndeplinind această cerință vor fi notificate.
Cum aflu dacă aplicația mea poate face excepție?
La o dată ulterioară, vor fi oferite instrucțiuni suplimentare privind excepțiile.
Cum gestionez situațiile de folosire a autentificării cu mai mulți factori (MFA)?
API-ul Restore Credentials nu gestionează solicitările MFA și nu este conceput pentru a ocoli politicile de securitate ale aplicației. La preluarea unei chei de restabilire pe un dispozitiv nou, aplicația trebuie să stabilească dacă este necesară o verificare suplimentară. Restabilirea contextului identității utilizatorului (de exemplu, afișarea mesajului „Bine ai revenit, Alex”) este suficientă pentru a îndeplini cerința. Totuși, reține că restabilirea de pe un dispozitiv pe altul oferă o dovadă solidă a posesiei și, prin urmare, nu ar trebui să necesite un pas MFA suplimentar.
De ce sunt scutite jocurile de această cerință?
Jocurile sunt scutite inițial deoarece lucrăm la soluții personalizate pentru situații de folosire complexe a autentificării, care sunt frecvente pentru jocuri. Jocurile care acceptă conectarea cu un singur cont sunt încurajate să adopte API-ul Restore Credentials pentru a accepta conectarea fără atingere.
Pot folosi Block Store pentru a îndeplini noile cerințe privind integrarea dispozitivelor?
Da, integrarea cu Block Store poate fi considerată conformă, dar numai dacă a fost finalizată și lansată în producție pe sau înainte de 30 septembrie 2026 și restabilește starea de conectare a unui utilizator. Alte tipuri de integrări sau cele finalizate după data limită nu sunt considerate conforme.
De ce există data limită de 30 septembrie 2026 pentru integrările cu Block Store?
Data de 30 septembrie 2026 oferă un termen-limită clar pentru echipele care integrează Block Store. Astfel, implementările existente ale conectării fără atingere rămân valide, iar integrările viitoare sunt direcționate către standardul Credential Manager recomandat.
Ce se întâmplă când utilizatorul se deconectează sau își șterge contul de pe vechiul dispozitiv?
Aplicația va trebui să șteargă activ cheia de restabilire. Dacă aplicația este dezinstalată, cheia de restabilire va fi ștearsă automat.
Ce fac cu utilizatorii în modul pentru invitați?
Cerința se aplică numai pentru partea aplicației care necesită autentificare. Dacă un utilizator a fost invitat pe dispozitivul vechi, aplicația trebuie să se lanseze în modul pentru invitați pe noul dispozitiv.
Ce fac cu utilizatorii care folosesc mai multe conturi pe același dispozitiv?
Pentru a îndeplini cerința, aplicația trebuie să stocheze cheia de restabilire pentru contul de utilizator activ momentan (sau ultimul cont activ) pe dispozitivul sursă. Află mai multe din documentația Restore Credentials.
Pot să trimit notificări utilizatorilor restabiliți fără să le solicit să acorde din nou permisiunile pentru notificări?
Da. Serviciile de backup și de restabilire gestionează restabilirea permisiunilor pentru aplicații, inclusiv a permisiunilor pentru notificări, de pe dispozitivul anterior. Astfel, poți să trimiți notificări generice. În plus, dacă folosești și Restore Credentials, poți să interacționezi din nou cu utilizatorii prin notificări personalizate pe noul dispozitiv, fără ca utilizatorul să deschidă mai întâi aplicația.
Altele
Aceste cerințe sunt opționale?
Toate cerințele postate pe această pagină sunt obligatorii. Nerespectarea unei cerințe poate afecta vizibilitatea și capacitatea de publicare ale unei aplicații pe Google Play.
Resurse utile
Optimizarea codului
- Activează optimizarea aplicației cu R8 | Calitatea aplicației | Android Developers
- Folosește R8 în modul complet | Calitatea aplicației | Android Developers
- Folosește R8 Configuration Analyzer | Calitatea aplicației | Android Developers
Utilizarea memoriei (RSS anonim + spațiul de înlocuire),
Utilizarea memoriei bitmap
Restore Credentials
- Despre Restore Credentials
- Ghiduri oficiale: Implementează Restore Credentials
- Materiale de testare: Date de conectare pentru testarea restabilirii în Android Studio
- Studiu de caz privind impactul în lumea reală: Cum a redus Uber numărul de conectări manuale cu 4 milioane pe an
Abilități
Abilitățile sunt instrucțiuni și resurse modulare, optimizate pentru AI, care ajută LLM-urile să înțeleagă și să execute mai bine anumite modele care respectă recomandările și instrucțiunile privind dezvoltarea pentru Android de la developer.android.com. Le poți folosi prin Android CLI sau alte instrumente bazate pe LLM.
- Abilitatea de analiză R8: analizează configurația R8 a unei aplicații și regulile de păstrare
- Abilitățile Perfetto AI: folosește-le pentru a interpreta datele privind memoria heap și pentru a primi sugestii utile de îmbunătățire a performanței memoriei
- Abilitatea Android Profiler: folosește-o pentru a interpreta datele privind memoria heap și urmele și pentru a primi sugestii utile de îmbunătățire a performanței memoriei
- Abilitatea Restore Credentials: folosește-o pentru ajutor la integrarea și testarea configurației pentru restabilirea datelor de conectare
Cerințe actuale
Cerințele tehnice existente pentru Google Play includ praguri pentru performanța slabă pentru un set de detalii de funcționare de bază, precum și cerințe referitoare la app bundle-ul pe care îl încarci în Play Console.
Detalii de funcționare de bază și stabilitate
Google Play monitorizează valorile de bază ale performanței pentru a se asigura că aplicațiile respectă standardele de stabilitate. Depășirea acestor praguri poate afecta vizibilitatea aplicației în Magazinul Google Play.
- Rata de blocări percepute de utilizatori: pragul de 1,09 % în general (media pe toate dispozitivele), 8 % pentru fiecare model de telefon și 4 % pentru fiecare model de ceas.Află mai multe
- Rata ANR percepută de utilizatori: pragul de 0,47 % în general (media pe toate dispozitivele), 8 % pentru fiecare model de telefon și 5 % pentru fiecare model de ceas. Află mai multe
- Stări excesive de activare parțială: prag de 5 % în general (media pe toate dispozitivele). Menținerea dispozitivului activ consumă inutil bateria. Folosește corect stările de activare și utilizează WorkManager pentru activitățile în fundal. Află mai multe
- Utilizarea excesivă a bateriei: prag de 1 % pentru fiecare model de ceas. Află mai multe
Cerințe tehnice
Google Play acceptă o gamă largă de dispozitive cu configurații și arhitecturi hardware diferite. Unele arhitecturi sunt fundamentale pentru viitorul Android și, prin urmare, noile app bundle-uri încărcate în Play Console trebuie să le accepte pentru a ne asigura că le putem oferi experiențele aplicației tale.
- Compatibilitate cu 64 de biți: aplicațiile care conțin cod nativ trebuie să accepte numai arhitecturi pe 64 de biți. Află mai multe
- Compatibilitate cu dimensiunea paginii de memorie de 16 KB: aplicațiile care conțin cod nativ trebuie să fie compatibile cu dispozitivele cu dimensiuni ale paginii de memorie de 16 KB. Aplicațiile care folosesc numai Java / Kotlin sunt compatibile în mod prestabilit. Află mai multe
- Compatibilitate cu Wear OS pe 64 de biți și cu dimensiunea paginii de memorie de 16 KB: obligatorie începând cu 15 septembrie 2026. Află mai multe
- Compatibilitate cu dimensiunea paginii de memorie de 16 KB și cu 64 de biți pentru televizor: obligatorie începând cu 1 august 2026. Află mai multe