Google объявила два новых обязательных требования к приложениям в Google Play: по расходу оперативной памяти и по восстановлению входа при переносе данных на новое устройство. Первое вступает в силу с февраля 2027 года и распространяется на приложения и игры, второе – с апреля 2027 года и касается только приложений. Причину ограничений в компании назвали прямо: из-за подорожания памяти новые устройства сохраняют или даже уменьшают объём ОЗУ, а требования пользователей к скорости работы остаются прежними. Тем, кто не уложится в пороги, грозит снижение видимости в каталоге и ограничение возможностей публикации. Оба требования объявлены .
Ограничения памяти в Android 17 и работа Memory Limiter
В Android 17 появились ограничения расхода памяти для отдельного приложения, рассчитанные от общего объёма ОЗУ устройства. Поначалу они действовали только на смартфонах Pixel. В течение ближайшего года, как сообщили в Google, ограничения станут применять всё больше производителей – для конфигураций от 4 до 16 ГБ и выше.
Реакция системы двухступенчатая. Когда приложение упирается в отведённый лимит, его страницы принудительно вытесняются в zRAM; сжатие и обратная распаковка нагружают процессор, из-за чего интерфейс начинает подтормаживать. Если расход продолжает расти, процесс завершается.
zRAM – область сжатых данных внутри самой оперативной памяти, куда система вытесняет редко используемые страницы вместо записи на накопитель.
Понять, что сеанс прервала именно эта защита, можно через ApplicationExitInfo: метод getDescription возвращает причину REASON_OTHER, а в строке описания присутствует MemoryLimiter:AnonSwap. Для автоматического сбора дампов кучи в момент срабатывания лимита предусмотрен триггер TRIGGER_TYPE_ANOMALY.
Поведение приложения под ограничениями проверяется через adb. Текущее состояние ограничителя выводит команда:
am memory-limiter status
Ручной лимит для конкретного процесса задаётся целым числом мегабайт, значение max снимает ограничения полностью, none возвращает системное значение по умолчанию:
am memory-limiter manual|max|none
Отдельная подкоманда выводит из-под контроля все процессы указанного приложения:
am memory-limiter ignore|none|all
Пороги расхода памяти: от 2 до 5 ГБ в зависимости от ОЗУ
Оценка идёт по метрике Memory usage (Anonymous RSS + Swap); русского названия у неё пока нет. Данные берутся за последние 28 дней, с порогом сравнивается значение 90-го процентиля. Требование действует для смартфонов и планшетов, а замеры собираются со всех версий начиная с Android 13, а не только с Android 17.
Анонимный RSS – объём страниц памяти, не связанных с файлами на накопителе: куча Java или Kotlin, нативные выделения и стеки потоков. Отбросить такие страницы под нагрузкой система не может, их остаётся только сжать в zRAM.
90-й процентиль – значение, ниже которого оказались 90% собранных замеров. Показатель 1,7 ГБ означает, что у оставшихся 10% замеров расход памяти был выше этой отметки.
Для приложений пороги распределены так:
| ОЗУ устройства | Активный режим | Сервисы, заметные пользователю | Фоновый режим |
|---|---|---|---|
| 4 ГБ (3200–4800 МБ) | 2 ГБ | 1 ГБ | 1 ГБ |
| 6 ГБ (4800–6800 МБ) | 2,25 ГБ | 1,25 ГБ | 1,25 ГБ |
| 8 ГБ (6800–9216 МБ) | 2,25 ГБ | 1,5 ГБ | 1,5 ГБ |
| 12 ГБ (9216–14 336 МБ) | 3,25 ГБ | 1,75 ГБ | 1,75 ГБ |
| 16 ГБ (14 336–18 432 МБ) | 4,25 ГБ | 2 ГБ | 2 ГБ |
Играм отведены более высокие значения. В Google объясняют разницу тем, что нагрузка у игр сосредоточена в активном режиме, а нативные движки накладывают собственные технические ограничения.
| ОЗУ устройства | Активный режим | Сервисы, заметные пользователю | Фоновый режим |
|---|---|---|---|
| 4 ГБ (3200–4800 МБ) | 2,25 ГБ | 2 ГБ | 2 ГБ |
| 6 ГБ (4800–6800 МБ) | 2,75 ГБ | 2,5 ГБ | 2,5 ГБ |
| 8 ГБ (6800–9216 МБ) | 3,5 ГБ | 2,75 ГБ | 2,75 ГБ |
| 12 ГБ (9216–14 336 МБ) | 4 ГБ | 3,2 ГБ | 3,2 ГБ |
| 16 ГБ (14 336–18 432 МБ) | 5 ГБ | 3,5 ГБ | 3,5 ГБ |
Для устройств с ОЗУ до 4 ГБ и свыше 18 432 МБ пороги не заданы, как и для кешированного состояния: оттуда система вытесняет процесс по своему усмотрению, поэтому замеры оставлены только для отладки. Границы уровней считаются по фактически доступной памяти, которая бывает меньше заявленного производителем объёма.
В справке Play Console приводится и способ отличить утечку от общего разрастания данных. Утечка накапливается со временем и растягивает хвост распределения, поэтому сравнивают 90-й процентиль с медианным значением по каждому процессу: превышение в 3,5 раза указывает на утечку при длительных сеансах.
Растровые изображения: 200 МБ в фоне и 400 МБ в кеше
Вторая метрика памяти, Bitmap memory usage, учитывает только растровые изображения. Порога для активного режима нет. Для сервисов, заметных пользователю, и для фонового режима предел составляет 200 МБ по 90-му процентилю, для кешированного состояния – 400 МБ.
Логика здесь простая: пока интерфейс скрыт, отрисовать растровое изображение невозможно, а держать его в памяти незачем. Ненулевые значения оставлены на случай, когда замер приходится на момент сразу после смены состояния и приложение ещё освобождает память по вызову onTrimMemory.
Среди рекомендуемых приёмов – декодирование изображений точно под размер отображаемой области, библиотеки загрузки с ограниченным кешем вроде Coil или Glide, освобождение изображений по TRIM_MEMORY_UI_HIDDEN и отказ от статических ссылок на объекты Bitmap и View.
Оптимизация DEX-кода: минимум 25% при размере свыше 10 МБ
Третье февральское требование касается не поведения приложения на устройстве, а самой сборки. Каждый загружаемый в Play Console набор обязан показывать не менее 25% по трём направлениям сразу: сжатие кода, оптимизация и обфускация.
DEX – формат байт-кода, в который компилируется код приложения на Java или Kotlin перед исполнением на Android.
Порог включается не у всех. Для приложений он применяется при размере DEX-кода свыше 10 МБ, для игр – свыше 50 МБ: у более компактных сборок влияние на память признано незначительным. В отличие от требований по памяти, это распространяется на все форм-факторы.
Использовать именно R8 не обязательно, подойдёт любой инструмент сжатия кода, хотя в документации настойчиво рекомендуют R8. Размер DEX и проценты по каждому направлению показываются для каждой загруженной сборки в обозревателе наборов приложений. Отдельно оговорено, что при сборке через CI/CD локальный результат может слегка расходиться с тем, что попадёт в Play Console.
Новые метрики и предупреждения в Play Console
Инструменты для подготовки к февральским порогам уже становятся доступны разработчикам:
- в Android Vitals добавлен раздел с метриками памяти, где расход разбит по процентилям, состояниям процесса и уровням ОЗУ, а также по именам процессов – включая процессы сторонних SDK;
- в разделе сбоев и ошибок ANR появился отдельный фильтр для случаев, когда приложение завершила система из-за нехватки памяти;
- в обозревателе наборов приложений выводятся показатели оптимизации DEX, если инструмент сжатия передаёт соответствующие метаданные;
- на странице обзора Android Vitals показываются предупреждения при превышении порогов, а также при неоптимизированных растровых изображениях и слабой оптимизации DEX;
- в Firebase Crashlytics версии 20.1.0 добавлены отладочные данные по нехватке памяти и завершениям процессов ограничителем.
До конца года обещаны ещё несколько диагностических инструментов: метрики времени, проведённого приложением в каждом состоянии, и подробные сведения о работе самого Memory Limiter.
Вход без нажатий при переносе на новое устройство
Второе требование относится к первому запуску приложения на новом смартфоне. С апреля 2027 года любое приложение с входом – обязательным или необязательным – должно само восстанавливать состояние сеанса, если пользователь перенёс данные напрямую с прежнего устройства или развернул облачную резервную копию.
Основной способ выполнить требование – Android Restore Credentials API, доступный начиная с Android 9. Приложение сохраняет ключ восстановления, который переносится вместе с данными, и при первом открытии на новом устройстве узнаёт пользователя без дополнительных нажатий. Ручной вход при первичной настройке в компании считают не только лишним шагом, снижающим удержание, но и уязвимым местом: именно на этом этапе работают фишинг и кража учётных данных.
Есть и технические ограничения. Ключ восстановления удаляется вместе с приложением при его удалении и не переживает переустановку на том же устройстве. Многофакторную проверку и запрос разрешений API не покрывает: восстанавливается только личность пользователя, а дополнительное подтверждение приложение при необходимости запрашивает самостоятельно. Требование распространяется на смартфоны и планшеты – для других форм-факторов API пока не поддерживается.
Исключения из требования и срок по Block Store
Список исключений опубликован вместе с самим требованием:
- приложения, у которых интеграция с Block Store для восстановления входа завершена и запущена не позднее , считаются соответствующими требованию; более поздние интеграции не засчитываются;
- приложения корпоративного управления устройствами и приложения с постоянно закрытым доступом под требование не подпадают;
- финансовые, медицинские и другие сервисы со строгими регуляторными обязательствами могут запросить исключение через Play Console, но сделать это нужно до даты вступления требования в силу;
- игры пока вне области действия; отдельные рекомендации для сложных схем авторизации в играх обещаны в течение 2027 года.
Играм с единственной учётной записью применить Restore Credentials API рекомендуют уже сейчас, не дожидаясь распространения требования на этот раздел каталога.
Подорожание памяти как причина новых порогов
Формулировка в справке Play Console резче, чем в блоге для разработчиков: там прямо говорится о надвигающемся кризисе памяти во всей экосистеме из-за роста цен на ОЗУ. Одно приложение с неконтролируемой утечкой забирает большую часть памяти устройства, после чего система начинает завершать корректно написанные приложения в фоне – и страдает вся платформа, а не только виновник.
Первопричина находится за пределами Android. Крупные поставщики памяти переориентировали мощности на продвинутые чипы для центров обработки данных, выпуск обычной памяти сократился, цены пошли вверх. Производители смартфонов ответили тем, что перестали наращивать объём ОЗУ в новых моделях. Насколько это ощутимо для отрасли, показывает отчётность второго квартала: у Xiaomi из-за подорожания компонентов прибыль снизилась на 43%, а валовая рентабельность смартфонного направления опустилась с 11,5% до 8,5%.
Отсюда и логика Google Play: если добавить памяти в устройства не получается, остаётся заставить приложения расходовать её экономнее.
Заключение
До февраля 2027 года у разработчиков есть время свести расход памяти к порогам и довести оптимизацию сборки до 25%, до апреля – внедрить восстановление входа. Метрики и предупреждения в Play Console уже работают, так что проверить своё положение относительно будущих порогов можно прямо сейчас.
Для пользователей смысл требований сводится к одному: на устройствах, где производитель сэкономил на ОЗУ, приложения должны перестать выталкивать друг друга из памяти, а перенос данных на новый смартфон – обходиться без череды повторных входов.