Особенности тестирования Android без Google-сервисов
Твой программистЧто такое AppGallery, AppGallery Connect и почему Huawei — без поддержки Google
Приложения под iOS- и Android-платформы можно встретить в официальных магазинах AppStore и Google Play. Туда мы идём в первую очередь, когда хотим установить новое мобильное приложение на телефон.
С 2018 года во всем мире (а в Китае — ещё раньше) появился другой магазин мобильных приложений — AppGallery, а с ним и AppGallery Connect.
AppGallery — это менеджер пакетов и платформа распространения приложений, разработанная Huawei для операционной системы Android. AppGallery Connect — универсальная платформа для поддержки всего жизненного цикла приложения: разработки, распространения, управления, тестирования и анализа.
За AppGallery последовал и выпуск устройств на базе Huawei: с 2019 года для них в принципе отсутствует возможность работать с Google-сервисами, поэтому работа с Android стала сложнее. Нужно было оперативно включиться в работу и придумать, как изменить процессы тестирования платформы.
Казалось бы, зачем менять процессы и подстраиваться под ещё один магазин? Как много багов может добавиться к уже существующим? Стоит ли тратить время и деньги? У нас есть два аргумента.
Во-первых, при разработке приложения автор ориентируется не только на качество ПО, но и на качество продукта. Если продукт доступен бОльшей части потенциальных клиентов, это говорит об ответственном подходе к приложению. Нам кажется, что работать с AppGallery можно и нужно, ведь пользователь — важное звено в разработке ПО.
Во-вторых, у AppGallery солидное количество пользователей. Магазин появился в 2018 году, к октябрю 2020 года приложение доступно в 170 странах мира, число уникальных пользователей – 700 миллионов человек. Как говорит статистика, ежемесячная аудитория составляет 490 миллионов активных пользователей.
При этом для Huawei написали всего 96 000 приложений. Для сравнения — в Play Store 2.9 миллиона приложений: это значит что более двух с половиной миллионов приложений отсутствуют в AppGallery.
В AppGallery нет, например, Instagram, Facebook и WhatsАpp. Их, конечно, можно скачать и установить вручную без ограничений: найти по отдельности в браузере или через какой-нибудь агрегатор. Также в сети появились сервисы, с помощью которых можно скачать самые популярные приложения. Но не каждый пользователь захочет выполнять дополнительные манипуляции.
Три вида Android-устройств
Как только к Android с Google-сервисами прибавились Huawei с сервисами HMS, некоторые устройства стали автоматически поддерживать оба вида сервисов (например, как Huawei до 2020 года выпуска).
Ниже представлено сравнение трёх типов устройств Android: с Google-cервисами, без них и с поддержкой обоих.

Устройства разные, особенности взаимодействия и тестирования — тем более. Казалось бы, все понятно: нужно знать, как с ними работать — и никаких проблем. Но ещё очень важно понимать, из чего составить этот рабочий процесс: как выбрать инструменты, чему обучить команду и к каким проблемам подойти с правильной стороны.
Возможности тестирования через AppGallery Connect
Проблемы начинаются при использовании разных библиотек на двух видах устройств Android. Мы в Surf пользуемся различными сервисами для работы с push-уведомлениями, аналитикой, dynamic или deep links, performance-мониторингом. Поэтому когда стали брать на вооружение работу с Huawei без Google-сервисов, волновались, насколько сильно изменится работа QA: получится ли тестировать push-уведомления и dynamic links в привычном ритме или придётся адаптироваться к абсолютно новому процессу? К счастью, сам процесс меняется несильно. Но есть вещи, о которых необходимо знать, прежде чем браться за работу с устройствами без поддержки Google.
Huawei без Google-сервисов не имеет доступа к инструментам, которые работают с Google, — например, Firebase. Сервисы для тестирования и работы мобильного приложения нужно настраивать через AppGallery (к счастью, AppGallery Connect имеет базовые возможности из коробки) или другие доступные инструменты. А возможно, придумывать и свои решения.
Ниже приведены базовые инструменты AppGallery Connect, позволяющие без особого труда наладить основные процессы по работе с пуш-уведомлениями, аналитикой, удалённой настройкой и прочими инструментами для удобства тестирования и поддержки.
Аналитика
При тестировании аналитики полезно просматривать события в реальном времени — это помогает обеспечить качество реализации отправки событий в мобильном приложении. Проверять аналитику в AppGallery Connect в реальном времени можно, например, с помощью «Отладки приложения» (аналогично DebugView в Firebase).
«Отладка приложения» (App Debugging) позволяет смотреть события, приходящие от МП, и их параметры в реальном времени. Чтобы подключить устройство к Отладке приложения в AppGallery Connect, нужно подключить устройство к компьютеру и в терминале выполнить команду:
adb shell setprop debug.huawei.hms.analytics.app <package_name>
Чтобы отключить устройство от отладки, выполнить команду:
adb shell setprop debug.huawei.hms.analytics.app .none.
Чтобы быстрее найти <package_name>, можно воспользоваться командой adb:
adb shell pm list packages
Общий сбор аналитики в AppGallery Connect тоже доступен. Он называется «Просмотр в реальном времени» (аналогично Events в Firebase)
«Просмотр в реальном времени» (Real-Time Overview) собирает все события с МП в одном месте. Можно строить графики по выбранным критериям, активировать фильтры и в целом проводить анализ по мобильному приложению.
Удалённая настройка и параметры
«Удалённая настройка» (Remote Configuration) позволяет управлять различными параметрами для приложения, и при необходимости обращаться к AppGallery Connect прямо из МП для работы с ними (аналогично RemoteConfig в Firebase).
Push-уведомления
При работе с push-уведомлениями Surf использует разные инструменты: Flocktory, Mindbox, Firebase и другие. Не все инструменты пока ещё могут работать с Android без поддержки Google, но базовая возможность подключить push-уведомления для Huawei есть: это их фирменная реализация через AppGallery Connect. Настройка пyшей происходит в PushKit.
Важно отметить, что пушер бэкэнда обязательно должен уметь взаимодействовать с AppGallery PushKit. Иначе push-уведомления придётся отправлять вручную из AppGallery Connect.
App Linking
App Linking — сервис для работы с dynamic links. На основании deep links App Linking предоставляет пользователям доступ к нужному контенту непосредственно на веб-страницах и в мобильных приложениях: это повышает конверсию пользователей (аналогично Dynamic Links в Firebase).
Dynamic Links vs Deep Links
На данный момент при работе с AppGallery Connect нет возможности создавать кастомные dynamic links: например, которые были бы одинаковыми и для обоих видов устройств Android (с поддержкой Google и без). Но c deep links всё в порядке.
Crash
Чтобы ловить незаметные с первого взгляда баги, стоит мониторить crash-аналитику даже на debug-версиях. Это необходимо, когда приложение потенциально разрабатывается на большую аудиторию и релиз близко — не говоря уже о ситуации, когда МП уже доступно магазине и им пользуется много людей.
Нам было важно, чтобы такой инструмент был доступен и для Huawei без Google-сервисов. Crash — плагин, позволяющий отслеживать и анализировать баги, краши и ошибки в приложении (аналогично Crashlytics в Firebase).
APM
Чтобы обеспечить качество клиент-серверного взаимодействия, удобно использовать инструмент, который бы помогал анализировать ответы от сервера и отрисовку экранов и элементов в приложении. В AppGallery Connect такой инструмент — APM. Это сервис, который помогает искать и устранять проблемы производительности приложения и улучшать таким образом пользовательский интерфейс (аналогично Performance в Firebase).
Конечно, это не все необходимые сервисы, которые можно встретить в мобильных приложениях, но они — базовые. Всегда приятно понимать, что не приходишь на «пустое поле»: есть с чем работать и можно сделать приложение лучше и доступнее для всех пользователей.
Особенности тестирования Android-платформы c поддержкой Huawei без Google-сервисов
В первое время при работе с устройствами Huawei без Google-сервисов мы тратили много времени на анализ и выстраивание процессов. Сейчас всё наладилось.
В целом можно выделить следующие проблемы и решения.
Шаринг сборок
На проектах мы часто шарим сборки через Firebase, или напрямую скачиваем .apk из Jenkins, или собираем вручную из Android Studio. Проблем со скачиванием или ручной установкой .apk для Huawei без Google-сервисов нет. Проблем с App Tester — приложением Firebase для шаринга сборок — тоже нет. Использовать непосредственно приложение не получится, но пройти по invite из почты в браузер для скачивания сборки удастся.
Лайфхак: сохраняйте страницу из браузера на рабочий стол телефона и не знайте горя.
Устройства
Конечно, для тестирования необходимы устройства и эмуляторы без Google-сервисов.
- Если на проекте планируется адаптация под AppGallery, можно отправить заявку Huawei. Они пришлют девайсы для тестирования. Правда, финальное слово всегда за самим Huawei: отправка запроса ничего не гарантирует. Но опция приятная.
- Неплохой вариант — использовать эмуляторы. Конечно, они не восполнят полную работу с устройством, но могут помочь в отдельных случаях.
- Можно работать с эмуляторами через ферму устройств App Gallery.
- Можно установить HMS Toolkit в Android Studio и работать с Huawei без Google-сервисов прямо из IDE.
На что обратить внимание
Стоит отметить важные моменты, которые впоследствии помогут избежать проблем или продумать пути их решения заранее.
1. Push-уведомления. На Huawei без Google-сервисов не будут работать push-уведомления, реализованные на backend через Firebase (а такое встречается сейчас часто). Такие устройства имеют свой hms-токен, и для работы с ними нужна специальная реализация.
2. Dynamic links. Инструмент AppGallery Connect не поддерживает кастомный формат dynamic links, поэтому нельзя настроить унифицированную ссылку на оба вида конфигураций устройств Android. Решение: использовать deep links или другой инструмент по работе с ссылками, работающий без Google Services.
3. Библиотеки с Google-сервисами. Различия в реализации и потенциальное скопление багов в логике будут, если в проекте используются библиотеки с Google-сервисами. Для Huawei их придётся заменить на другие фреймворки или if-ответвления. Тогда понадобится более тщательно тестировать оба вида устройств.
- Google Pay. На Android без Google-сервисов можно столкнуться с окном «Оплата недоступна, так как для нее нужен доступ к Google-сервисам, которые ваше устройство не поддерживает». Аналогичную ошибку можно встретить при запуске других приложений, не предназначенных для Huawei без Google.
- Google-карты. Работа с Google-картами может содержать проблемы с кластеризацией, поиском, отрисовкой текущего местоположения и так далее.
- Google-аккаунт. Авторизация через Google-аккаунт на Huawei без поддержки Google недоступна. Но реализация авторизации-регистрации через Huawei-аккаунт была бы кстати.
- Магазины. Если мобильное приложение может отправить пользователя в магазин (для оценки, например), то необходимо проверить, что Android без Google Services отправляет в App Gallery, а Android с поддержкой Google — в Google Play. Если устройство поддерживает обе конфигурации, было бы здорово, если бы пользователь мог выбрать между магазинами.
4. Сервисы с поддержкой Google. Для Huawei без Google придётся найти аналоги или разработать их самостоятельно. Хорошо, что важные базовые инструменты, как упоминалось выше, доступны в AppGallery Connect из коробки.
Например, на Android-устройствах можно открывать ссылки из приложения тремя разными способами:
- WebView,
- CustomTabs (разработка Google),
- браузер.
Для Huawei без поддержки Google, по умолчанию доступны только два способа или дополнительная разработка вручную.
Android с Google и без: сколько времени понадобится на тестирование
Базовые активности QA:
- планирование,
- ревью ТЗ и дизайна,
- написание проверок,
- прогоны по фиче, итоговые, регрессионные,
- написание отчётности
Это пример активностей QA «в среднем по больнице». Мы исключаем особенности компании и проектов и говорим немного в вакууме.
При работе с Huawei без Google-сервисов точно добавляется время к каждой из активностей:
- Ревью ТЗ и дизайна, написание проверок. Будут дополнительные кейсы, отражающие особенности работы с такими устройствами. Можно смело увеличивать оценку временных затрат на это в 1,4–1,6 раза. Здесь время уйдёт либо на обработку дополнительных сценариев в ТЗ и дизайне, либо на анализ и подтверждение, что никакой особенной реализации для Android без Google-сервисов нет.
- Прогоны. Во время прогонов (по фиче, итоговых, регрессионных) рекомендуется проводить тестирования как на Android с Google-сервисами, так и без. Особое внимание — устройствам, где доступны оба вида сервисов. Здесь сокращение количества устройств может когда-нибудь неприятно «выстрелить». Время может увеличиться в 1,8–2 раза и уйдёт на осуществление прогона на всех трёх видах устройств.
- Обратная связь. Под «обратной связью» мы в Surf подразумеваем просмотр маленьких задач (которые не требует прогона по фиче — например, «Смену статичного текста») и исправленных багов. При работе с обратной связью, а также при анализе и просмотре импакта от багов и прочих задач, снова не стоит забывать про тот же список устройств (без и с Google-сервисами, а также с двумя видами сервисов) для тестирования. Время увеличивается примерно в 1,3 раза снова для того, чтобы осуществить ретест или проверку задачи на этих видах устройств.
- Послерелизные активности. При релизе приложения в AppGallery необходимо продолжать мониторить работу МП как минимум по crash-сервису, чтобы поддерживать качество и исправлять ошибки вовремя. Если в проекте не используется один инструмент мониторинга обоих видов устройств, то времени на работу с двумя инструментами и анализом багов будет уходить больше. Пожалуй, тут лучше увеличить время в 2 раза.
- Тестируемые устройства. И, конечно, на время может повлиять количество выбранных устройств для тестирования (автоматизированного или ручного). Подходить к выбору устройств стоит ответственно, проанализировав множественные факторы проекта и аудитории.
При тестировании на Android с Google Services хочется покрыть наибольшее количество устройств: разные операционные системы, оболочки, разрешения экранов, внутренние особенности и возможности. Устройств становится ещё больше, когда добавляются девайсы Huawei с HMS-сервисами.
Таким образом, необходимо покрыть бОльшее количество устройств: не забывая про Android с Google-сервисами, Android без их поддержки, и Android с поддержкой HMS-сервисов помимо Google.
На процесс и время могут повлиять особенности работы конкретной компании. Если у вас есть дополнительные задачи, активности, роли, рекомендуем провести предварительный анализ, чтобы не столкнуться с неожиданностями «в бою».
Время общего тестирования фичи увеличится:
- в 1,8–2 раза в случае разных инструментов для реализации фичи;
- в 1,3–1,5 раза в случае одного инструмента для реализации фичи (в том числе при отсутствии отличий на первый взгляд);
- в 1,4–1,6 раза в случае дополнительных требований и отличительной части реализации.
Таблица-сравнение по тестированию фичи для устройств с Google и без
Мы оценили фичи по пунктам, о которых говорили выше ревью, написание проверок, прогоны по фиче, обратная связь.

Что хотелось бы сказать в конце...
Мы в Surf поддерживаем устройства Huawei без Google-сервисов на некоторых проектах и довольны процессами. Конечно, поработать головой иногда приходится чуть дольше: разработчикам — чтобы найти универсальное решение. QA — чтобы найти максимальное количество дефектов, широко покрыть фичи проверками и обеспечить качественное тестирование. И на мой взгляд, оно того стоит.