Размещал ли приложение в AppGallery

Короткий ответ: Да, размещал приложение в AppGallery. В рамках одного из проектов, который был ориентирован на китайский рынок, публикация в Huawei AppGallery была обязательным требованием, так как сервисы Google Play недоступны в Китае. Я участвовал в полном цикле адаптации и публикации, что дало мне глубокое практическое понимание специфики этой платформы.

## Почему нужен AppGallery и отличия от Google Play

Основная причина использования Huawei AppGallery — доступ к огромному рынку пользователей устройств Huawei и Honor, особенно в Китае и других регионах, где Google Mobile Services (GMS) отсутствуют. Это не просто альтернативный магазин, а полноценная экосистема, требующая адаптации.

Ключевые отличия и особенности:

• Отсутствие GMS: Приложение не может использовать сервисы Google (FCM, Maps, Sign-In, Play Billing). Вместо них необходимо интегрировать Huawei Mobile Services (HMS).
• Сервисы HMS: Аналоги практически для всех ключевых функций: HMS Push Kit (вместо FCM), Account Kit (авторизация), IAP Kit (платежи), Location Kit, Map Kit, Analytics Kit и т.д.
• Процесс проверки (App Review): Может быть более строгим и детальным, особенно в вопросах безопасности и соответствия политикам контента. Время проверки иногда дольше.
• Инструменты разработчика: Основная работа ведется через Huawei Developer Console (аналог Google Play Console). Для сборки используется AppGallery Connect и плагины для AGP (Android Gradle Plugin).

## Мой опыт адаптации и публикации

Процесс можно разделить на несколько ключевых этапов, в которых я принимал непосредственное участие:

1. Регистрация и настройка проекта в Huawei Developer Console:

    *   Создание проекта и приложения, получение **агентского ключа (agconnect-services.json)** — конфигурационного файла, аналогичного `google-services.json`.
    *   Настройка подписей приложения, сертификатов для подписи, управление релизами.

1. Техническая адаптация кода:

    *   **Условная компиляция:** Мы использовали флаги продукта (product flavors) в Gradle для разделения логики GMS и HMS, чтобы не дублировать код.

```kotlin
// build.gradle (module)
android {
    flavorDimensions "store"
    productFlavors {
        gms {
            dimension "store"
            // Добавляем специфичные зависимости GMS
        }
        hms {
            dimension "store"
            // Добавляем специфичные зависимости HMS
        }
    }
}
```

    *   **Создание слоя абстракции:** Критически важные сервисы (например, пуш-уведомления, аналитика, аутентификация) были обернуты в интерфейсы, реализации которых подключались в зависимости от флавора.

```kotlin
// Общий интерфейс для пуш-сервисов
interface PushService {
    fun getToken(callback: (String?) -> Unit)
    fun subscribeToTopic(topic: String)
}

// Реализация для GMS (FCM)
class FcmPushService : PushService { ... }

// Реализация для HMS (Push Kit)
class HmsPushService : PushService { ... }
```

    *   **Интеграция конкретных Kits HMS:** Замена библиотек и API. Например, для карт приходилось полностью менять фрагмент с `MapView` от Google на `MapView` от Huawei, что затрагивало инициализацию, обработку маркеров и камеры.

1. Тестирование:

    *   Обязательное тестирование на реальных устройствах Huawei без GMS.
    *   Использование **Huawei Cloud Debugging** для тестов на удаленных устройствах разных моделей.
    *   Валидация работы всех интегрированных Kits HMS.

1. Сборка, подпись и отправка на модерацию:

    *   Сборка отдельного APK (или AAB) для флавора `hms`.
    *   Загрузка в AppGallery Connect, заполнение всех метаданных (описания, скриншоты, промо-материалы) — часто требуется локализация на китайский язык.
    *   Подготовка ответов на потенциальные вопросы модерации.

## Основные выводы и сложности

• Планирование: Интеграцию HMS необходимо закладывать в архитектуру на ранних этапах проекта. Рефакторинг "готового" приложения под HMS — трудоемкий и рискованный процесс.
• Архитектура — ключ к успеху: Использование чистой архитектуры, Dependency Injection (Dagger/Hilt) и абстракций над платформенно-зависимыми сервисами — это не просто best practice, а необходимость для поддержки нескольких экосистем.
• Двойная нагрузка на поддержку: После публикации приходится поддерживать две отдельные сборки, следить за обновлениями двух наборов SDK (GMS и HMS), тестировать две цепочки функциональности.
• Документация и сообщество: Документация HMS на английском хороша, но иногда встречаются нюансы. Русскоязычное сообщество меньше, чем вокруг GMS, поэтому чаще приходится разбираться самостоятельно.

Таким образом, опыт публикации в AppGallery — это ценный навык, который демонстрирует не только умение работать с конкретным SDK, но и понимание важности создания гибкой, расширяемой архитектуры Android-приложения, способной адаптироваться к требованиям разных рынков и платформ.