Perioada de grație pentru API 36 din Google Play s-a încheiat, iar termenele de permisiuni din 2027 sunt deja stabilite

Din 31 august 2026, Google Play acceptă doar aplicații noi și actualizări de aplicații care țintesc Android 16 (API level 36) sau mai nou. Aplicațiile pentru Wear OS, Android Automotive OS, Android TV și Android XR sunt scutite. Echipele care aveau nevoie de mai mult timp puteau cere o prelungire până la 1 noiembrie 2026. Data aceea a trecut. Dacă targetSdkVersion este încă sub 36, nu poți publica acum nicio actualizare în Play, inclusiv hotfix-ul de care ai putea avea nevoie săptămâna viitoare.

Aplicațiile existente, care nu sunt actualizate, au o regulă separată. Trebuie să țintească cel puțin Android 15 (API level 35) ca să rămână disponibile pentru utilizatorii noi, pe dispozitive cu o versiune de Android mai nouă decât ținta aplicației. Sub acest nivel, aplicația apare doar pe dispozitivele cu aceeași versiune de Android sau una mai veche. Așadar, o aplicație la care nu s-a umblat de mult nu este retrasă, dar devine tot mai greu de găsit.

În plus, pe 29 octombrie 2026 Google a anunțat un set de modificări de politică, cu date de aplicare distribuite pe parcursul lui 2027. Niciuna nu e urgentă astăzi. Toate sunt genul de lucruri care se transformă în panică dacă le observi cu două săptămâni înainte de termen.

Calendarul pentru 2027

Iată datele din tabelul Policy Deadlines al Google și de pe pagina de politici Play:

• 27 ianuarie 2027: contacte. Politica Contacts Permission restricționează accesul larg la contactele utilizatorilor. Aplicațiile care nu au nevoie de acces larg trebuie să folosească Android Contact Picker.
• 27 ianuarie 2027: locație precisă. Aplicațiile care țintesc Android 17 (API 37+) trebuie să folosească butonul de locație Android pentru cereri de locație precisă, unice sau rare. Dacă păstrezi ACCESS_FINE_LOCATION, ai nevoie de o declarație în Play Console care explică de ce nu sunt suficiente butonul de locație sau locația aproximativă.
• 27 ianuarie 2027: reduceri la abonamente. Abonamentele cu reduceri permanente, condiționate de eligibilitate, precum planurile pentru studenți, trebuie să prezinte clar criteriile de eligibilitate, modul de verificare și ce se întâmplă cu prețul și cu beneficiile după ce utilizatorul nu mai este eligibil.
• 14 aprilie 2027: AppFunctions. AppFunctions nu trebuie să păcălească sau să manipuleze agenții AI, să ocolească controalele lor de securitate sau să interfereze cu alte aplicații.
• 25 august 2027: ACCESS_LOCAL_NETWORK. Accesul la rețeaua locală este restricționat la aplicațiile care au nevoie de el pentru funcționalitatea de bază, atunci când selectoarele de dispozitive precum NsdManager nu sunt suficiente. Aplicațiile care țintesc Android 17 sau mai nou au nevoie de o declarație în Play Console pentru a-l folosi.
• 25 august 2027: MANAGE_CONTACTS. Restricționat la aplicațiile a căror funcționalitate de bază îl cere, atunci când selectoarele de sistem nu sunt suficiente, cu o declarație în Play Console. Toți ceilalți trebuie să folosească intent-uri de platformă cu domeniu îngust.

De ce creșterea target API prinde echipele nepregătite an de an

În proiectele noastre Android native, ridicarea targetSdkVersion rareori e partea grea. Schimbarea unui număr în Gradle durează un minut. Munca stă în tot ce activează acel număr: comportamente noi ale platformei la care aplicația ta aderă acum, biblioteci care nu au ținut pasul și dispozitive de test care nu acoperă noua versiune. Am văzut o modificare de o singură linie transformându-se într-un sprint de trei săptămâni, pentru că un SDK de plăți sau o bibliotecă BLE nu lansase încă o versiune compatibilă.

Cel mai des vedem următorul tipar: aplicația funcționează, nimeni nu e alocat pe ea, iar cerința de target API apare ca un avertisment în Play Console, care ajunge într-o căsuță de e-mail comună. Apoi apare un bug real, remedierea e gata, iar încărcarea este respinsă. Acum faci o migrare de platformă sub presiune, cu o problemă deschisă în producție. În situația asta se află multe echipe chiar în această săptămână.

Opinia mea sinceră: tratează creșterea anuală a target API ca pe o dependență a ta, nu ca pe o corvoadă impusă de Google. Pune-o în roadmap în fiecare primăvară, când e anunțată noua cerință, și fă-o cât timp nu arde nimic.

Modificările de permisiuni contează mai mult decât par

Regulile din 2027 au o idee comună. Permisiunile largi sunt înlocuite cu selectoare și butoane de sistem, iar dacă vrei să păstrezi varianta largă, trebuie să te explici în Play Console.

Am observat asta cel mai clar la aplicațiile din sănătate și IoT. Aplicațiile IoT cer de obicei acces la rețeaua locală devreme, pentru că descoperirea dispozitivelor este primul ecran, și e ușor să ceri mai mult decât ai nevoie. Dacă un selector construit pe NsdManager acoperă fluxul tău de descoperire, regula din august 2027 înseamnă în mare parte hârtii pe care le poți evita. Dacă nu, începe de acum să notezi de ce funcționalitatea de bază are nevoie de permisiune, pentru că exact asta cere declarația.

Contactele stau similar. Multe aplicații cer acces complet la contacte pentru un singur ecran de tip „invită un prieten”. Contact Picker acoperă cazul acesta, iar trecerea la el înainte de ianuarie elimină o permisiune de care utilizatorii oricum se feresc. Din perspectiva securității, e și o veste bună. În angajamentele noastre de pentesting, permisiunile prea largi sunt o constatare recurentă: date de care aplicația nu a avut niciodată nevoie, stocate într-un cache local, la îndemâna oricui obține un punct de sprijin pe dispozitiv. Mai puțin acces înseamnă mai puțin de scurs.

Regula butonului de locație se aplică doar când ții Android 17 ca target, dar dacă livrezi un localizator de magazine sau un câmp „folosește locația mea” la checkout, planifică acum modificarea interfeței. Un buton cu o singură atingere e un flux diferit față de un dialog de permisiune la runtime, iar designerii vor vrea să aibă un cuvânt de spus.

Nu ignora regulile pentru abonamente și AppFunctions

Regula de transparență pentru abonamente se ratează ușor, pentru că ține de zona de produs și de cea juridică, nu de cod. Dacă oferi un plan pentru studenți sau alt plan condiționat de eligibilitate, cineva trebuie să noteze procesul de verificare și prețul de după pierderea eligibilității chiar pe ecranul de plată. În proiectele web și backend pe care le facem pentru clienți enterprise, o astfel de cerință înseamnă de obicei o modificare atât a textelor din aplicație, cât și a serverului care decide cine mai este eligibil, așa că implică echipa de backend din timp.

AppFunctions e teren mai nou. Politica e scurtă: nu păcăli agenții AI, nu le ocoli controalele de securitate, nu interfera cu alte aplicații. Dacă expui acțiuni ale aplicației către agenți, verifică-le așa cum ai verifica un API public. Vezi ce poate face fiecare funcție fără confirmarea utilizatorului și presupune că ceva o va apela cu date de intrare la care nu te-ai gândit.

Ce ai de făcut săptămâna aceasta

1. Verifică astăzi nivelul target API. Dacă e sub 36, upgrade-ul blochează acum fiecare release. Fă un branch, ridică versiunea, rulează toată suita de teste pe un dispozitiv Android 16 și actualizează orice bibliotecă ce se strică.
2. Auditează manifestul. Listează toate utilizările READ_CONTACTS, MANAGE_CONTACTS, ACCESS_FINE_LOCATION și ACCESS_LOCAL_NETWORK și notează lângă fiecare dacă un selector sau un buton l-ar putea înlocui.
3. Pune datele din 2027 într-un calendar comun, cu un responsabil pentru fiecare, nu doar un memento pe Slack.
4. Alocă pe cineva pe inbox-ul Play Console. Cea mai mare parte a problemelor pe care le vedem începe cu un avertisment pe care nu l-a citit nimeni.

Dacă vrei să vezi cum am gestionat înainte migrări de platformă ca aceasta, portofoliul nostru are câteva exemple, iar munca noastră de dezvoltare acoperă atât Android nativ, cât și backend-urile din spatele lui.

Dacă un targetSdkVersion blocat sau un audit de permisiuni pe care îl tot amâni ți se par cunoscute, hai să vorbim.