25 Августа 2026 10:00 25 Авг 2026 10:00 |

Поделиться

Google меняет правила установки Android-приложений. Что делать?

Главные вопросы и ответы

Затронет ли верификация Россию 30 сентября 2026? — Нет. Первая волна коснется Бразилию, Индонезию, Сингапур и Таиланд. Россия под санкциями — устройства в таких регионах Google исключает из обязательной проверки.

«Сломаются» ли корпоративные приложения на Android? — Нет, если они распространяются через MDM на управляемых устройствах или установлены на устройства без сервисов Google.

Нужно ли срочно регистрироваться как проверенный разработчик? — Необязательно, но рекомендуем сделать это для приложений, которые потенциально могут устанавливаться за пределами корпоративного контура.

Что делать ИТ-директору сейчас? — Проверить, какие устройства используются в компании, есть ли на них сервисы Google, как устанавливаются корпоративные приложения и какие из них являются критичными для бизнеса. Это поможет заранее выявить сценарии, которые могут зависеть от дальнейшего распространения правил Google.

Что меняется?

Google вводит Android Developer Verification — механизм, который проверяет происхождение приложения. Разработчик должен быть зарегистрирован у Google, а подпись приложения связана с его учетной записью.

Это не то же самое, что Play Protect. Он проверяет приложения на наличие вредоносного кода, верификация же подтверждает разработчика и его связь с конкретным приложением. Оба механизма работают независимо друг от друга.

Проверка проходит непосредственно на устройстве. На сертифицированных устройствах с Android 8 и выше отдельный системный компонент Android Developer Verifier распространяется через сервисы Google Play.

Верификация не рассчитана не на Android-устройства. Если на устройстве отсутствуют сервисы Google, Android Developer Verification на нем не запустится. Это касается устройств с Android-сборками без Google Play, AOSP и других систем без сервисов Google.

Отдельное исключение — приложения, которые распространяются через корпоративный магазин. Они вообще не должны проходить дополнительную верификацию разработчика — их безопасность уже проверена ИТ-администратором. Но Google все же рекомендует разработчикам зарегистрировать эти приложения, на случай если их будет устанавливать пользователь за пределами управляемого контура или на устройстве без MDM.

То есть сама по себе новая система не отменяет возможности централизованно управлять корпоративным ПО.

Нет необходимости срочной миграции, но подготовка будет полезна

С учетом изменений принципиально важно не рассматривать весь парк Android-устройств как единую среду. Условно их можно разделить на три группы. Возможны различные сценарии в зависимости от наличия на устройствах сервисов Google и способа распространения приложений.

1. Сервисы Google не установлены. Верификация на таких устройствах не работает. Модель распространения приложений через MDM, локальные каталоги или APK не меняется.

2. Сертифицированные Google устройства под управлением MDM. Исключение из обязательной верификации. Сам по себе переход на новые правила не должен менять такой сценарий распространения. Важно — если пользователь получает APK из внешнего источника, это уже другой сценарий.

3. Сертифицированные устройства без корпоративного контроля распространения приложений. Именно этот сценарий потенциально представляет больший интерес при дальнейшем расширении правил. Если приложение устанавливается вручную или через публичный либо сторонний магазин, в перспективе может потребоваться подтверждённый статус его разработчика.

Для критичных внутренних приложений это означает необходимость заранее понимать, где и каким образом они могут использоваться.

Чек-лист ИТ-директора до осени 2026: шесть шагов

• Провести инвентаризацию мобильного парка. Для каждого типа устройства стоит определить наличие сервисов Google, версию Android и факт управления через MDM.
• Составить карту распространения корпоративных приложений. Для каждого решения важно зафиксировать разработчика, ключ подписи и фактический канал установки: MDM, Google Play, внутренний портал или APK.
• Выделить критичные внутрикорпоративные приложения. Особого внимания требуют мобильные рабочие места сотрудников, программное обеспечение для складов, логистики и производства, а также другие приложения, остановка распространения которых может повлиять на бизнес-процессы.
• Проверить управление ключами подписи приложений. В компании должно быть понятно, кто контролирует ключ, кому передают права при смене ответственных и как организовано управление учётными записями разработчиков. Потеря контроля над ключом подписи может привести к проблемам с обновлением приложения, и не только из-за новых правил Google.
• Проверить сценарии в оффлайне. Возможная «серая зона» — официально никак не описывается, как будет проходить верификация, если сертифицированное устройство надолго осталось без связи с облаком. Возможно, Android Developer Verifier пользуется локально сохранёнными данными и обновляет их через сервисы Google Play.
• Назначить ответственного за отслеживание изменений. Пока обязательная верификация будет введена лишь ограниченно, но Google планирует постепенно расширять географию.

Где пока остается неопределенность

Для корпоративной инфраструктуры остается еще три проблемы, на которые пока нет однозначных ответов.

Главная — как именно определяется регион устройства для применения санкционного исключения. Google не раскрывает, используется ли для этого IP-адрес, оператор связи, регион учетной записи или комбинация нескольких признаков.

Еще один вопрос — работа верификации без подключения к интернету. Неясно, как долго Android Developer Verifier сможет использовать сохранённые на устройстве сведения о разработчиках и что произойдёт при установке приложения, информация о котором ещё не была получена устройством.

Третий момент — последующая трактовка исключения для MDM. Сейчас Google прямо указывает, что приложения из корпоративного магазина на управляемых устройствах не требуют верификации. Однако при дальнейшем распространении механизма правила могут меняться.

Что произойдет, если правила изменятся

Если в ближайшее время обязательная верификация распространится на российские устройства или корпоративные сценарии, наиболее прямым решением станет регистрация разработчиков в Google и привязка к ним соответствующих подписей. SafeMobile уже прошёл такую проверку и верифицирован по всем новым правилам.

Если такая регистрация невозможна, Google предусматривает альтернативные сценарии установки, включая ADB и расширенный режим установки. Но для корпоративного парка они имеют ограничения.

ADB подходит прежде всего для разработки и отладки приложений и не является полноценной моделью массового распространения корпоративного ПО.

Расширенный режим требует дополнительных действий на самом устройстве: включения режима разработчика, подтверждения намерения пользователя, перезагрузки и ожидания. Для управляемого корпоративного парка такой сценарий также сложно рассматривать как штатный способ распространения критичного ПО.

Поэтому уже сейчас имеет смысл понимать, какие приложения зависят от конкретного канала установки и что произойдёт, если этот канал перестанет работать.

Поделиться

Подписаться на новости Короткая ссылка