Публікація Android-додатка в RuStore: повний гайд

Публікація в RuStore: де ламається реліз Android-застосунку

Публікація в RuStore ламається не на етапі завантаження файлу, а раніше — на невідповідності збірки вимогам магазину. Найчастіша причина відхилення — підпис застосунку: релізний ключ втрачено або перестворено, і магазин бачить новий сертифікат як інший застосунок.

Оновлення поверх старої версії в цьому випадку не встановиться, а користувачі залишаться на попередній збірці без можливості отримати виправлення.

Друга лінія збоїв — політики магазину. Модерація відхиляє збірку за дозволи, які не підтверджені функціональністю, за поведінку при першому запуску без згоди на обробку даних, за рекламні ідентифікатори без явного призначення.

Формально застосунок працює, але перевірку не проходить — і реліз вирушає на повторне коло, втрачаючи тижні.

Третій пласт — технічний стан самої збірки. Різні версії бібліотек у межах одного проєкту, невідповідність цільової та мінімальної версії системи, відсутність 64-бітних варіантів, недієвий відкат при помилці оновлення.

Це не помилки компіляції, а розбіжності між тим, що зібрано, і тим, що магазин готовий прийняти та розповсюдити.

Ми розбираємо такі релізи крок за кроком: звіряємо підпис і ланцюжок сертифікатів, проходимо за чек-лістом політик до надсилання, перевіряємо сумісність версій і сценарії оновлення на реальних пристроях.

Публікація в RuStore перестає бути лотереєю, коли кожен пункт перевірено до модерації, а не після відхилення збірки.

Що дає вибудуваний процес випуску оновлень

Вибудуваний процес випуску прибирає головну статтю втрат у підтримці застосунку — час між готовим кодом і оновленням у магазині.

Коли збірка, підпис, перевірки та відправлення на модерацію йдуть одним відпрацьованим маршрутом, реліз перестає бути подією на тиждень і стає рутинною операцією.

Швидкість релізу зростає не за рахунок «швидше писати код», а за рахунок того, що між комітом і публікацією більше немає ручних пауз і погоджень.

Частка відхилених збірок — друга метрика, яка напряму залежить від процесу. Магазин відхиляє не лише за функціональні дефекти: причинами стають невідповідність політиці, неповні описи, неправильні дозволи, розбіжність підпису при оновленні.

Якщо ці перевірки вбудовані в конвеєр до відправлення, а не виконуються очима перед публікацією, кількість повернень падає передбачувано — типові причини відсікаються автоматично.

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

Регресійні перевірки на реальних пристроях, а не лише на емуляторах, ловлять саме ті дефекти, які проявляються у частини аудиторії та псують рейтинг.

Підтримка застосунку після релізу — це не лише виправлення помилок, а й керування версіями: поетапне розгортання, можливість швидко відкотити проблемну збірку, окремі канали для тестувальників.

Коли такий контур налаштований, команда випускає оновлення частіше й дрібніше, а кожен реліз несе менше ризику. Розбираємо, як це влаштовано на практиці.

Способи публікації: ручне завантаження, автоскладання, гібрид

Вибір способу випуску визначає, скільки ручної роботи припадає на кожен реліз і наскільки швидко команда відкочується при збої.

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

Коли релізи виходять раз на місяць, це виправдано — накладні витрати нижчі, ніж на налаштування автоматизації.

Автоматизація збірки окупається при частих випусках: конвеєр збирає пакет, проганяє перевірки, підписує і сам вивантажує артефакт у консоль розробника.

Гібридний реліз — компроміс: збірка й тести автоматизовані, а фінальне надсилання на модерацію та роботу з карткою веде людина, щоб контролювати текст і скриншоти.

На практиці більшість команд приходить до гібриду: конвеєр знімає рутину зі збірки та підпису, а консоль розробника залишається точкою усвідомленого рішення про випуск.

Такий режим дає передбачуваний час від коміту до появи версії у користувачів і дозволяє відкотитися на попередню збірку без перезбирання.

Етапи випуску: від аудиту застосунку до передачі доступів

Випуск у RuStore — це не «залити файл і чекати». Магазин перевіряє збірку, картку та права на бренд, а відмова на будь-якому кроці повертає реліз на початок черги. Тому ведемо процес етапами, з фіксацією результату на кожному.

Як влаштована робота

1. Аудит застосунку. Дивимося поточну збірку: цільові версії системи, дозволи, поведінку без мережі, обробку згортання, роботу фонових завдань. Окремо — що застосунок запитує в користувача і як пояснює ці запити. На виході список правок, без яких перевірку не пройти.
2. Підготовка збірки. Збираємо підписаний релізний артефакт, виставляємо версію і код версії, прибираємо налагоджувальні логи та тестові адреси серверів. Перевіряємо, що ключ підпису зберігається окремо і переданий замовнику — втрата ключа блокує оновлення.
3. Налаштування картки. Заповнюємо назву, опис, категорію, віковий рейтинг, скриншоти та графіку під вимоги магазину. Тут же — політика конфіденційності та відомості про платежі, якщо вони є.
4. Перевірка перед відправленням. Проганяємо збірку на реальних пристроях різних класів, перевіряємо встановлення, оновлення поверх попередньої версії та видалення. Ловимо падіння до модерації, а не після.
5. Відправлення та проходження модерації. Публікуємо збірку, відстежуємо зауваження перевіряльників і відповідаємо по суті. Типові причини повернення — невідповідність опису функціональності та спірні дозволи.
6. Публікація та поетапне розгортання. Випускаємо на частку аудиторії, стежимо за відмовами та відгуками, потім відкриваємо на всіх. Так збій не зачіпає весь потік користувачів.
7. Передача доступів. Віддаємо замовнику володіння акаунтом розробника, ключ підпису, доступи до консолі та коротку інструкцію з випуску оновлень.

Кожен етап закінчується артефактом: звіт аудиту, підписана збірка, заповнена картка, протокол перевірки. За ними видно, де процес стоїть і що залишилося до релізу.

Що замовник отримує після публікації

Публікація в RuStore — це не фінальна кнопка, а точка передачі проєкту замовнику. Після неї у вас на руках має залишитися комплект, з яким команда зможе випускати оновлення без нас: підписані збірки, документація, доступи та регламент. Нижче — що саме входить у передачу і навіщо кожен пункт потрібен на практиці.

• Підписані збірки. Релізний APK/AAB і debug-варіант, підписані ключем проєкту, із зазначенням відбитка сертифіката. Без коректного підпису RuStore відхилить завантаження, а оновлення поверх встановленої версії не встановиться.
• Ключі підпису та їх зберігання. Keystore, паролі та інструкція з безпечного зберігання. Втрата ключа означає, що застосунок не можна оновити під тим самим ідентифікатором — доведеться публікувати заново.
• Доступи до акаунтів. Облікові записи розробника в RuStore, консолі магазину та пов'язаних сервісів, оформлені на замовника, а не на підрядника. Плюс ролі для ваших співробітників.
• Документація зі збірки. Опис середовища, залежностей і команд збірки, щоб реліз відтворювався на чистій машині, а не лише на комп'ютері автора.
• Регламент оновлень. Порядок випуску версій: як готується збірка, хто затверджує, як заповнюється картка і що робити при відхиленні модерацією.
• Інструкція по картці застосунку. Опис, скриншоти, іконки та тексти у форматі, придатному для повторного використання при наступному релізі.
• Порядок відкатів. Що робити, якщо нова версія ламає сценарій: як швидко повернути попередню збірку і як повідомити користувачів.

Такий комплект знімає залежність від конкретних людей: оновлення може випустити будь-який інженер команди, а не лише той, хто вів проєкт. Якщо потрібно — обговоримо задачу і повернемося з оцінкою та планом передачі.

Кейс: як прискорили випуск оновлень утричі

До роботи релізний цикл займав 9–12 днів: збірка вручну на локальній машині, підпис артефакту «на око», ручне завантаження в консоль, очікування перевірки та окремий етап розкатки на пристрої.

Кожен випуск тягнув за собою техборг — частину правок просто відкладали до наступного вікна, бо запускати процес заново було дорожче, ніж зачекати.

Що змінили

Зібрали конвеєр збірки та публікації: збірка запускається за тегом, артефакт підписується автоматично, версія та номер збірки проставляються з історії змін. Далі — автоматичне надсилання в RuStore через API, роздільні канали для внутрішнього тестування та продуктивної розкатки.

Окремо налаштували поетапний випуск: спочатку 10% аудиторії, потім 50%, потім усі — з автоматичним відкатом за часткою помилок.

Метрики до і після

Ключове — не сама швидкість, а те, що вона перестала бути разовою акцією. Раніше команда накопичувала правки, щоб не запускати важкий процес зайвий раз; тепер випуск іде невеликими порціями, і кожна порція перевіряється на обмеженій аудиторії.

Частка відкатів упала в п'ять разів саме через це: помилка ловиться на 10% користувачів, а не на всій базі.

Окремий ефект — передбачуваність. Терміни випуску перестали залежати від того, хто з інженерів вільний у конкретний день: конвеєр однаково працює і в п'ятницю ввечері, і в розпал відпусток.

Чим відрізняється публікація в RuStore від Google Play?

Процедурно RuStore ближчий до Google Play, ніж здається: той самий формат AAB, той самий консольний кабінет, той самий принцип поетапного розгортання на частку аудиторії. Відмінності починаються у вимогах до збірки та в тому, як магазин перевіряє застосунок перед публікацією.

RuStore жорсткіше ставиться до нативних бібліотек і явно вимагає вказувати цільовий рівень API, а також обмежує набір дозволів, які застосунок запитує в користувача — зайві пункти в маніфесті стають причиною відмови на модерації.

Google Play, своєю чергою, робить ставку на автоматизовані перевірки та політики безпеки: сканування коду, аналіз поведінки, вимоги до декларації про збір даних.

RuStore перевіряє застосунок швидше й охочіше пропускає нішеві збірки, але уважніше дивиться на інтеграцію з платежами та на те, як застосунок працює без сервісів Google.

Якщо у вас є залежність від Google Play Services — карти, push, авторизація — її доведеться замінити на альтернативи, інакше частина функцій відвалиться в користувачів RuStore.

Окрема відмінність — робота з платежами. У Google Play вбудовані покупки йдуть через білінг магазину, у RuStore є свій платіжний механізм, і підписки потрібно перепідключати під нього. Це не переписування застосунку, але помітний обсяг роботи в шарі оплати.

За строками модерації RuStore зазвичай відповідає швидше, ніж Google Play, і рідше повертає на доопрацювання через формальні причіпки. Зате в Google Play ширші інструменти аналітики та тестування — закриті треки, внутрішні групи, передрелізні звіти. У RuStore частина цих можливостей є, але в урізаному вигляді.

Головна відмінність для команди — не в самій публікації, а в підтримці двох гілок збірки. Один код, дві конфігурації, різні залежності та різні платіжні модулі.

Якщо закладати це на старті, публікація в RuStore проходить без переробок; якщо додавати другим магазином до готового застосунку — доведеться повозитися з платіжним шаром і замінами сервісів Google.

Часті технічні питання при публікації

Перед публікацією майже кожна команда стикається з одним і тим самим набором питань: скільки чекати перевірки, що робити з підписом при оновленні, як не отримати відмову на тестуванні. Нижче — відповіді на технічні сумніви, які найчастіше виникають на цьому етапі.

Що буде з підписом при випуску оновлення?

Оновлення має бути підписане тим самим ключем, що й перша версія, інакше магазин відхилить завантаження. Ключ і паролі зберігаємо в захищеному сховищі з резервною копією: втрата ключа означає неможливість оновлювати застосунок під тим самим ідентифікатором.

Якщо ключ утрачено в попереднього підрядника, розбираємо варіанти — від відновлення доступу до випуску під новим ідентифікатором з міграцією користувачів.

Як проходить тестування перед публікацією?

Збираємо збірку, проганяємо її на закритому каналі та перевіряємо сценарії, які найчастіше ламаються: перший запуск, авторизація, оплата, робота без мережі, оновлення поверх попередньої версії. Окремо дивимося поведінку на слабких пристроях і старих версіях системи.

Тільки після цього надсилаємо на перевірку — так відмова на модерації не перетворюється на втрачені дні.

Чи можна відкотити невдале оновлення?

Так, попередня версія залишається доступною, і ми повертаємо її як актуальну, поки готуємо виправлення. Тому релізи виходять поетапно: спочатку на частку користувачів, потім на всіх. Якщо метрики падають — зупиняємо розкатку до того, як проблема торкнеться всієї аудиторії.

Чи потрібно публікувати застосунок заново при зміні підрядника?

Ні. Ми запитуємо доступи до акаунта розробника, переносимо ключі підпису та продовжуємо випускати оновлення під тим самим ідентифікатором — користувачі не втрачають застосунок і не перевстановлюють його. Якщо доступи втрачено, допомагаємо відновити їх через підтримку магазину.

Якщо вашого питання немає в списку — опишіть ситуацію, повернемося з оцінкою та планом робіт.

Обговоримо ваше завдання щодо випуску застосунку

Щоб випустити застосунок у RuStore без сюрпризів на етапі модерації, ми спочатку розбираємо ваш продукт і лише потім називаємо терміни.

Розмова починається не з шаблонного «зробимо під ключ», а з конкретики: що за застосунок, які сценарії критичні, чи є вже збірка та акаунт розробника. За підсумками обговорення ви отримуєте оцінку та план робіт, де кожен етап прив'язаний до результату.

Як проходить робота

• Розбір завдання. Уточнюємо тип застосунку, цільові пристрої, вимоги до авторизації, платежів і сповіщень. Фіксуємо, що вже готово, а що належить зібрати.
• Перевірка готовності до RuStore. Дивимося підписаний релізний пакет, версію, цільову платформу та політику конфіденційності. Частина відмов модерації знімається ще до подання.
• Оцінка та план. Узгоджуємо обсяг робіт, порядок випуску та точки, де потрібне ваше рішення. Ви бачите, скільки займе кожен крок.
• Підготовка збірки. Налаштовуємо підпис, версіонування та параметри публікації під вимоги магазину.
• Заповнення картки. Готуємо опис, категорію, скриншоти та графику — від цього залежить, як застосунок знайдуть користувачі.
• Подання та модерація. Надсилаємо збірку, відстежуємо статус і оперативно відповідаємо на зауваження перевіряльників.
• Випуск і підтримка. Публікуємо реліз, стежимо за відгуками та готуємо оновлення в міру розвитку продукту.

Якщо у вас уже є застосунок під іншу платформу, окремо оцінюємо перенесення та адаптацію — це впливає на терміни та обсяг. Опишіть завдання: тип застосунку, поточний статус і бажаний термін випуску. Повернемося з оцінкою та планом робіт.