Вимоги Google Play 2026: як опублікувати застосунок
Свіжий target API, форма Data safety, заборонка і тест із живими людьми - без болю
Вимоги Google Play для публікації застосунку: свіжий target API level, чесна форма Data safety, заборонка і обовʼязкове закрите тестування. Що перевіряють і як пройти з першого разу.
Що таке вимоги Google Play простими словами
Ти зібрав застосунок, тиснеш «опублікувати» - і в голові картинка, як він зараз красиво летить у магазин. А впираєшся в стіну з правил. Знайомо? Ще б пак.
Дивись на це так. Google Play - це аеропорт із паспортним контролем. Застосунок - твій пасажир. Щоб потрапити на рейс, він проходить кілька стійок: показує свіжий паспорт, чесно заповнює декларацію, не тягне заборонку у валізі, проходить огляд. Завалить хоч одну стійку - розвернуть прямо біля трапа.
Стійок рівно чотири: свіжий target API level Target API level (цільовий рівень API) - число в налаштуваннях застосунку, яке каже, під яку версію Android ти орієнтувався під час збірки. Що вище число, то новіший Android. Google змушує тримати його свіжим, щоб застосунки грали за новими правилами безпеки. , форма Data safety, відсутність заборонки та пройдене тестування. Пройдімося по кожній.
Навіщо розробнику знати вимоги стору
Можна, звісно, кинути застосунок «як є» і сподіватися на удачу. Тільки Google перевіряє все - і автоматикою, і руками модераторів. Відмова прилітає не одразу, а через дні очікування. А повторна перевірка - знову в кінець черги. Задоволення так собі.
- Зрозумієш, чому застосунок відхилили, і перестанеш ворожити на кавовій гущі.
- Не схопиш блокування акаунта за те, що можна було передбачити на старті.
- Заповниш форму Data safety один раз і нормально, а не сім разів із правками.
- Заощадиш тижні. Перевірки йдуть по черзі, і кожна відмова відкидає тебе назад.
Більшість відмов у новачків - це не «поганий код». Це прострочений дедлайн по target API, крива анкета про дані або забуте тестування. І все це видно заздалегідь.
Чотири перевірки Google Play по порядку
1. Target API level - покажи свіжий паспорт
Google не хоче, щоб у сторі доживали свій вік застосунки, зібрані за старими правилами безпеки. Тому планка target API щороку повзе вгору: нові застосунки й оновлення мають цілитися у свіжу версію Android, зазвичай торішню.
На практиці це означає ось що. Приблизно з кінця літа до стору пускають лише те, що націлене на актуальний рівень API. Під Wear OS, Android TV та автомобільні системи планка зазвичай на сходинку нижча.
targetSdkVersion targetSdkVersion - рядок у налаштуваннях збірки Android (файл build.gradle), де стоїть те саме число target API level. Саме його Google перевіряє під час завантаження. Підняти зазвичай нескладно, але іноді доводиться лагодити те, що зламалося через нові правила. піднімається в налаштуваннях збірки. І ось тут засідка ховається не в самому числі. Нова версія Android могла змінити правила гри: якісь дозволи посилилися, якийсь звичний спосіб щось робити просто перестав працювати. Тож після підняття обовʼязково проганяй застосунок і перевір - нічого не відвалилося?
2. Форма Data safety - чесна декларація на митниці
Data safety Data safety - розділ у картці застосунку, де розробник чесно перелічує, які дані збирає застосунок, навіщо, чи передає їх комусь і як захищає. Користувач бачить це в магазині ще до встановлення. - це анкета, у якій ти сам розповідаєш, що застосунок робить із даними користувача. Імʼя, email, геолокація, рекламний ідентифікатор пристрою - усе це треба задекларувати.
І ось тут новачки горять найчастіше. Рахуються й ті дані, що збирають чужі бібліотеки та SDK всередині твого застосунку. Встромив рекламу чи аналітику - усе, ти теж збираєш дані. Навіть якщо сам їх пальцем не торкався.
- Збір даних. Усе, що застосунок відправляє з пристрою назовні - на сервер, в аналітику, у рекламу.
- Передачу третім особам. Чи ділишся даними з іншими компаніями і заради чого.
- Захист. Чи шифруєш дані під час передачі і чи можна запросити їх видалення.
- «Та я нічого не збираю». А рекламний SDK тихо тягне ідентифікатор пристрою за тебе - це треба вказати.
- Забути про сторонні бібліотеки. Їхній збір даних - твоя відповідальність, не їхня.
- Збрехати «по-швидкому». Google звіряє анкету з реальною поведінкою. Розбіжність - відмова або бан.
3. Заборонка - що не можна везти у валізі
Є теми, за які видаляють одразу і без листування. Це не «понизимо у видачі». Це «приберемо застосунок, а заразом можемо закрити й акаунт».
- Дитяча безпека - абсолютний пріоритет і нульова толерантність. Будь-який контент, що експлуатує дітей, - миттєве видалення.
- Обман і шахрайство - фейкові сервіси, оманливі схеми, застосунки, які вводять в оману.
- Дипфейки і підробки - сексуальні дипфейки без згоди, підроблені записи реальних людей під шахрайство.
- Контент, згенерований ШІ, грає за тими самими правилами, що й звичайний. Генерує застосунок картинки чи текст - він зобовʼязаний блокувати заборонене.
- Чутливі дозволи - доступ до контактів, фото, геолокації має бути виправданим. Кредитним і мікропозиковим застосункам, наприклад, лізти у фото й контакти прямо заборонено.
4. Тестування - огляд перед вильотом
Завів новий особистий акаунт розробника? Тоді Google не пустить тебе одразу в продакшен. Спершу проганяй закрите тестування з живими людьми.
«Поспіль» - це означає безперервно. Зайшла людина, побула три дні, вийшла - не зарахують. Навіть якщо повернеться пізніше. Тож збирай тих, хто реально готовий тримати застосунок встановленим два тижні.
Як опублікувати застосунок у Google Play: покроково
Ось реалістичний порядок дій, якщо публікуєшся вперше.
- Підніми target API level до актуального рівня в налаштуваннях збірки. Прожени застосунок і переконайся, що після підняття нічого не зламалося.
- Склади список УСІХ бібліотек і SDK у проєкті. Перевір, які з них збирають дані користувача - це теж твоя відповідальність.
- Заповни форму Data safety чесно: що збираєш, навіщо, кому передаєш, як захищаєш. Звір анкету з реальною поведінкою застосунку.
- Підготуй політику конфіденційності й дай на неї робоче посилання - без неї картку не приймуть.
- Перечитай Developer Program Policy щодо заборонки. Переконайся, що твоя тема й дозволи в межах.
- Акаунт новий і особистий? Запусти закрите тестування, збери живих тестувальників і протримай тест два тижні поспіль.
- І лише після цього подавай на доступ до продакшену й публікуй. А перед самою подачею ще раз відкрий офіційну довідку Play Console - цифри й дедлайни могли оновитися.
Часті помилки під час публікації в Google Play
- Проспати дедлайн по target API. Планка стрибає щороку. Зібрав під торішні правила пізніше строку - оновлення завернуть. Звіряйся з довідкою.
- Вважати Data safety формальністю. Це звірювана декларація. Розійшлася з реальністю - спершу відмова, потім блокування.
- Забути про чужі SDK. Реклама й аналітика збирають дані за тебе. А в анкеті за них відповідаєш ти.
- Лізти в заборонку «через незнання». Незнання правил від бану не рятує. Перечитай Developer Program Policy до подачі.
- Думати, що дозволи «зайвими не будуть». Просиш доступ до контактів чи фото без явної потреби - отримаєш відмову. Бери мінімум.
- Ігнорувати тестування на новому акаунті. Без закритого тесту з живими людьми в продакшен просто не пустять. Закладай два тижні заздалегідь.
- Вірити цифрам зі старих статей. Числа тестувальників, рівні API й дедлайни змінюються. Джерело істини одне - офіційна довідка Play Console.
TL;DR - если коротко
- Google Play - це паспортний контроль. Чотири стійки, і кожну треба пройти - інакше до стору не пустять.
- Target API level тримай свіжим. Планка для нових застосунків і оновлень щороку стрибає на нову версію Android. Старе розвертають.
- Форма Data safety - чесна анкета про дані. Заповнюєш сам, Google звіряє, брехати не можна.
- Заборонка - дитяча безпека, обман, дипфейки, зайві дозволи. За це видаляють мовчки.
- Тестування - новому особистому акаунту спершу потрібен закритий тест із живими людьми, і лише потім продакшен.
- Цифри й дедлайни застарівають. Перед публікацією звіряйся з довідкою Play Console.