Google Play alkaa valvoa Android-sovellusten muistinkäyttöä ja kirjautumista

Google Play nostaa Android-sovellusten teknistä laatukynnystä. Helmikuusta 2027 alkaen sovelluksia ja pelejä arvioidaan uusien niin sanottujen haitallisen toiminnan rajojen perusteella. Tarkastelussa ovat dynaaminen muistinkäyttö, bittikarttamuisti ja DEX-koodin optimointi. Raja-arvot ylittäville sovelluksille voidaan määrätä heikompi näkyvyys Google Playssa ja rajoituksia julkaisemiseen – kyse ei kuitenkaan ole automaattisesta sovelluksen poistamisesta kaupasta.

Huhtikuussa 2027 voimaan tulee erillinen kirjautumista koskeva vaatimus. Kirjautumista käyttävien sovellusten on tuettava Zero-Tap Sign-In -toimintoa, joka palauttaa käyttäjän kirjautumistilan Android-laitteen vaihdon yhteydessä Restore Credentials -järjestelmän avulla. Pelit on tällä hetkellä rajattu tämän vaatimuksen ulkopuolelle. 17

Mitä Google Play alkaa mitata?

Uusi suorituskykypolitiikka keskittyy kolmeen alueeseen, jotka voivat aiheuttaa sovellusten hidastumista, kaatumisia tai tehotonta jakelua.

1. Dynaaminen muistinkäyttö

Google mittaa sovelluksen anonyymiä resident set size -kokoa eli RSS-arvoa sekä pakattua swap-muistia. Mittaus kohdistuu sovelluksen ajonaikana käyttämään yksityiseen muistiin, eikä kaikkea laitteelle tallennettua koodia tai sisältöresursseja lasketa sovelluksen muistinkäytöksi.

Pelien etualan dynaamisen muistin rajat skaalautuvat laitteen RAM-määrän mukaan. Ilmoitettu vaihteluväli on 2,25 gigatavua 4 gigatavun RAM-laitteilla ja 5 gigatavua 16 gigatavun RAM-laitteilla. Google Play aikoo siis arvioida sovellusten toimintaa eri laiteluokissa yhden kaikille laitteille sopivan kiinteän rajan sijaan.

2. Bittikarttamuisti

Bittikarttojen eli kuvamuodossa käsiteltävien grafiikkaresurssien käyttöä seurataan sovelluksen etuala-, tausta- ja välimuistitiloissa. Raja-arvot ovat:

• 200 Mt, kun sovellus on etualalla tai taustalla
• 400 Mt, kun sovellus on välimuistissa

Tavoitteena on estää kuvien ja muiden visuaalisten resurssien tarpeeton säilyminen muistissa silloin, kun niitä ei enää näytetä käyttäjälle.

3. DEX-koodin optimointi

Pelit, joiden DEX-koodin määrä ylittää 50 Mt, tarvitsevat vähintään 25 prosentin App Bundle -kattavuuden koodin optimoinnin, pienennyksen ja obfuskoinnin avulla. Kehittäjät voivat käyttää esimerkiksi R8-työkalua tai muuta pienennystyökalua turhan koodin poistamiseen ja jaeltavan sovelluspaketin tehostamiseen.

Miten vaatimuksia valvotaan?

Google Play ei perusta arviota yhteen poikkeuksellisen raskaaseen käyttökertaan. Rajat lasketaan 90. persentiilin eli P90-arvon perusteella, ja tiedot kerätään liukuvalla 28 päivän ajanjaksolla. Käytännössä tämä tarkoittaa, että huomio kohdistuu pitkäkestoisiin ja todellisessa käytössä toistuviin suorituskykyongelmiin, ei yhteen pahimpaan yksittäiseen mittaustulokseen.

Vaatimukset alittaville sovelluksille voi seurata heikompi näkyvyys ja rajoituksia julkaisumahdollisuuksiin Google Playssa. Google ei ole kuvannut seuraamusta automaattiseksi kielloksi tai kaikkien raja-arvon ylittävien sovellusten poistamiseksi kaupasta. Kehittäjille on lisäksi tulossa Play Consoleen seuranta- ja diagnostiikkatyökaluja, joiden avulla dynaamisen muistin ja bittikarttojen mittareita voi tarkkailla jo ennen valvonnan alkamista.

Raja-arvot voivat muuttua, kun Google saa lisää tietoa eri laite- ja sovellusluokkien suorituskyvystä. Kehittäjien kannattaa siksi pitää julkaistuja lukuja jatkuvan seurannan lähtötasona, ei kertaluonteisena hyväksyntätestinä.

Zero-Tap Sign-In helpottaa puhelimen vaihtamista

Huhtikuussa 2027 alkava toinen muutos koskee eri asiaa: uuden Android-laitteen käyttöönottoa. Kirjautumista käyttävien sovellusten on tuettava Zero-Tap Sign-In -toimintoa, joka palauttaa käyttäjän kirjautumistilan laitteen vaihdon yhteydessä Androidin Restore Credentials API -rajapinnan avulla.

Restore Credentials toimii Credential Managerin kautta. Sen tarkoitus on kirjata käyttäjä huomaamattomasti takaisin sisään, kun sovellus palautetaan uudelle laitteelle. Toiminto voi toimia sovelluksen ensisijaisesta tunnistautumistavasta riippumatta – käytössä voi olla esimerkiksi salasana, passkey-avain tai ulkopuolisen palvelun tarjoama kirjautuminen. 1719

Muutos vähentää tarvetta kirjautua manuaalisesti jokaiseen sovellukseen puhelimen vaihdon jälkeen. Pelit on tällä hetkellä vapautettu vaatimuksesta, mutta poikkeus voi vielä muuttua, kun Google kehittää käytäntöä eteenpäin.

Miten tämä liittyy Android 17:ään?

Google Playn uudet vaatimukset täydentävät Android 17:n käyttöjärjestelmätason muistirajoja eivätkä korvaa niitä. Android 17 tuo sovelluskohtaiset muistirajat, jotka perustuvat laitteen kokonais-RAM-määrään. Ominaisuus otettiin aluksi käyttöön Pixel-laitteilla, ja Google odottaa yhä useampien valmistajien hyödyntävän rajoja 4 gigatavun ja yli 16 gigatavun RAM-laitteissa.

Jos sovellus ylittää Android 17:n muistirajan, käyttöjärjestelmä voi hidastaa sitä ja lopulta lopettaa sovelluksen prosessin. Playn uudet vaatimukset toimivat aiemmin jakeluketjussa: niiden tarkoitus on kannustaa kehittäjiä pienentämään muistinkulutusta ja optimoimaan koodia ennen kuin käyttäjä törmää käyttöjärjestelmän rajoituksiin omalla laitteellaan.

Ero on käytännössä tärkeä. Android 17 määrittää, mitä sovellukselle voi tapahtua sen ollessa käynnissä tietyllä laitteella. Google Playn vuoden 2027 säännöt taas vaikuttavat siihen, saako sovellus jatkossakin normaalin näkyvyyden ja julkaisumahdollisuudet sovelluskaupassa.

Mitä Android-kehittäjien kannattaa tehdä nyt?

Suurten sovellusten ja pelien kehittäjien kannattaa aloittaa ainakin näistä toimista:

1. Tarkistaa anonyymin RSS-muistin ja pakatun swap-muistin käyttö etu- ja taustatilanteissa.
2. Seurata bittikarttamuistia erillään yleisestä kekomuistin käytöstä ja huomioida myös välimuistitila.
3. Tarkistaa DEX-koodin koko sekä koodin pienennyksen, optimoinnin ja obfuskoinnin tuottama App Bundle -kattavuus.
4. Testata sovellusta useilla RAM-tasoilla eikä ainoastaan tehokkailla huippupuhelimilla.
5. Seurata Play Consolen tulevia diagnostiikkatyökaluja ja Android Vitals -mittareita.
6. Käydä läpi sovelluksen tunnistautumisprosessi ja suunnitella Restore Credentials -tuen käyttöönotto ennen huhtikuuta 2027.

Kehittäjille viesti on selvä: muistitehokkuus ja koodin optimointi eivät ole enää vain hyviä suorituskykykäytäntöjä. Niistä on tulossa myös jakelukriteerejä. Valmistautumattomat sovellukset voivat edelleen toimia, mutta niiden näkyvyys ja julkaisuoikeudet Google Playssa voivat heikentyä, ja ne joutuvat aiempaa useammin Androidin omien muistirajoitusten kohteeksi.