Перед публикацией приложения в Google Play лучше не надеяться, что модерация сама покажет все косяки. Проверять стоит весь комплект заранее: AAB, SDK, разрешения, Policy, Data Safety, листинг, графику и возможные пересечения с другими приложениями. В этой статье разберем, что можно проверить руками, где реально помогает AI и как Phoenix автоматизирует часть этой рутины до отправки прилки в стор.
Как проверить приложение перед публикацией в Google Play: что смотреть в первую очередь
Перед публикацией лучше смотреть не только на сам билд. Минимум стоит проверить AAB и Policy, а в идеале еще пройтись по листингу, графике и Data Safety. Потому что косяк может быть не внутри приложения, а, например, в описании или декларации.
Дальше уже по техничке: SDK, разрешения, подпись, метаданные и то, как все это между собой связано. Отдельно стоит сверить, что описание и скрины реально соответствуют приложению, а Policy и Data Safety не расходятся с тем, что прилка делает по факту.
Проверка AAB: SDK, разрешения и технические проблемы
Начинать логично с самого AAB. Тут смотрим, какие SDK зашиты внутрь, какие разрешения просит прилка и нет ли в сборке лишнего, что вообще не используется в функционале. Иногда какая-нибудь библиотека подтягивает разрешение автоматически, а потом именно оно вызывает лишние вопросы.
Плюс стоит проверить сам билд на технические косяки, подпись и другие данные внутри сборки. Смысл простой: перед публикацией лучше понимать, что именно лежит внутри AAB, а не узнавать об этом уже после реджекта.
Совпадает ли листинг с реальным приложением
Следом смотрим витрину: название, описание, иконку и скрины. Они должны показывать именно ту прилку, которую человек получит после установки.
Особенно это актуально, когда приложение собирали или дорабатывали через AI. Бывает, что внутри уже один интерфейс, а в стор случайно улетают старые скрины или вообще другая иконка. Такие мелочи легко пропустить, если перед публикацией никто нормально не прошелся по всему комплекту руками.
Policy и Data Safety: где чаще всего появляются несостыковки
Здесь главная проблема обычно не в самой форме, а в том, что написанное в ней не совпадает с реальным поведением приложения.
Например, в Data Safety указали, что данные не собираются, а внутри стоит аналитический или рекламный SDK, который их все-таки собирает. То же самое с Policy: она должна описывать то, что прилка реально делает, а не просто существовать для галочки.
Поэтому перед отправкой лучше сверять Policy и Data Safety уже после проверки SDK и разрешений. Тогда намного проще заметить, где декларации расходятся с фактической сборкой.
Если хотите глубже разобраться в теме Google Play, посмотрите еще два материала: за что Google банит приложения и аккаунты разработчиков и как выбрать поставщика Google Play-консолей.
Как найти пересечения с другими приложениями
Еще одна штука, которую есть смысл проверить до публикации, — случайные пересечения с другими прилками. Это может быть одинаковая подпись, сервисы, адреса серверов, графика, тексты или другие технические идентификаторы.
У Phoenix для этого собирается внутренняя база: бот сравнивает загруженную прилку с тем, что уже проверял раньше, и может подсветить найденные совпадения. Особенно полезно, когда через одну команду проходит много проектов и руками держать все это в голове уже нереально.
Где в проверке помогает AI
Часть вещей можно проверить обычными правилами, но где-то уже нужен анализ по смыслу. Например, понять, соответствует ли описание реальному функционалу или не расходятся ли Policy и Data Safety с тем, что находится внутри сборки.
В боте Phoenix собрано 74 правила Google Play, а AI подключается как раз для таких смысловых проверок. Саму систему калибровали на базе более чем 1000 белых и серых приложений, чтобы бот не просто орал на все подряд, а пытался отделять реальные проблемы от ложных срабатываний.
Что должен показывать отчет перед публикацией
Просто написать «тут что-то подозрительное» особо никому не поможет. Поэтому у Phoenix по каждой найденной проблеме бот показывает, что именно нашел, насколько это критично, на чем основан вывод и что стоит исправить. Плюс дает ссылку на соответствующее правило Google Play.
В конце прилка получает общий вердикт: можно публиковать, можно, но есть замечания, нельзя публиковать или не хватает данных для проверки. Уже намного понятнее, куда копать перед отправкой в стор.
Что автоматическая проверка все равно не увидит
При этом даже такой бот не превращается в хрустальный шар. Он не видит историю аккаунта разработчика, не знает, что происходило с ним раньше, и не запускает приложение как полноценный пользователь. Проверка идет по тем файлам и данным, которые ему передали.
Плюс база пересечений у Phoenix своя, а не вся база Google Play. Поэтому вердикт «можно публиковать» не означает, что Google точно пропустит прилку. Это скорее дополнительный фильтр, который помогает найти часть косяков еще до того, как их найдет модерация.
