Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет! Меня зовут Мария Лещинская, я QA-специалист в Surf. Наша компания разрабатывает мобильные приложения с 2011 года. В этом материале поговорим о тестировании устройств Android, на которых нет поддержки Google Services.
Huawei без Google-сервисов начали массово выпускаться в 2019 году. Мы в Surf, разумеется, задумались о будущем: как сильно пострадают наши процессы и что нужно незамедлительно осваивать.
Я поделюсь впечатлениями от работы с Android без Google-сервисов и расскажу, какие возможности имеют такие мобильные устройства при тестировании.
В начале статьи — общая информация про AppGallery и AppGallery Connect. Если вы всё это уже знаете, переходите сразу к сути — к особенностям тестирования Android-платформы c поддержкой Huawei без 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ервисами, без них и с поддержкой обоих.
Android без Google-сервисов | Android только с Google-сервисами | Android с поддержкой Google-сервисов и App Gallery | |
.apk/.aab | Установочный файл может быть один — на все виды устройств Android, или их может быть два: отдельно с сервисами Huawei и отдельно с сервисами Google. Мы в Surf обычно делаем один .apk/.aab для обоих видов устройств Android. Логика работы приложений на разных устройствах определена внутри сборки. Но также могут быть два установочных файла одного приложения: один идёт в Google play, другой — в AppGallery. На мой взгляд, удобнее использовать именно один установочный файл для тестирования и релиза в различные магазины. Проще и быстрее сделать одну сборку, чем две, но как только подключается CI, разница минимизируется. Использование двух сборок теоретически может уменьшить вес приложения — особенно если в нем используются разные фреймворки для реализации фич на Android с Google Services и без. | ||
инструменты | AppGallery Connect и сервисы, не использующие Google. | Сервисы, использующие google, — в том числе Firebase. | AppGallery Connect, сервисы, не использующие Google, и сервисы, использующие Google — в том числе Firebase. Какие инструменты выбрать, стоит продумать до начала разработки: проанализировать особенности проекта и устройств, потенциальную аудиторию, сервисы, необходимые для реализации фич. |
При работе с Huawei без Google-сервисов всегда нужно помнить про отсутствие возможности работы с Google-сервисами. Как бы тавтологично это не звучало, бывают моменты, когда уже готовые решения, которые можно использовать в разработке определённого проекта, опираются на сервисы Google. Какие-то сразу об этом сообщают — тогда проблем нет. Какие-то используют их глубоко в фреймворке, и тогда приходится немного «покопаться» в реализации. Если такая библиотека случайно попадёт в приложение, используемое на Huawei без поддержки Google, могут возникнуть проблемы. Именно поэтому важно тестировать отдельно и на таких устройствах тоже. | |||
баги | Баги по общей логике приложения, конечно, будут распространяться на оба вида устройств. Существенные отличия могут появиться при работе сервисов типа Google Pay, push-уведомлений, deep links и dynamic links и так далее. | ||
Устройства разные, особенности взаимодействия и тестирования — тем более. Казалось бы, все понятно: нужно знать, как с ними работать — и никаких проблем. Но ещё очень важно понимать, из чего составить этот рабочий процесс: как выбрать инструменты, чему обучить команду и к каким проблемам подойти с правильной стороны.
Возможности тестирования через 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
Dynamic links — это интеллектуальные URL-адреса, которые позволяют отправлять существующих и потенциальных пользователей в любое место в приложении iOS или Android. Dynamic links легко переводят пользователей с любого URL на контент в приложении. Если пользователь не установил приложение на устройство, он увидит контент, когда установит его.
Deep Links — это тип локальных ссылок: они направляют пользователей непосредственно в приложение — и только. Соответственно, если приложение не установлено, работа с deep links невозможна.
Простыми словами, dynamic links — ссылки, которые могут редиректить пользователя откуда угодно прямо в приложение или магазин, если оно не установлено (а после установки — и в приложение). 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 и без
Мы оценили фичи по пунктам, о которых говорили выше ревью, написание проверок, прогоны по фиче, обратная связь.
Фича | Поддержка Android только с сервисами Google | Поддержка Android с Huawei и Google Services |
Авторизация по логину и паролю, а также через соц.сети | X | 1,5X |
Push-уведомления (реализация через Firebase и AppGallery Connect) | X | 1,8X |
Аналитика, около 15 событий (реализация через Firebase и AppGallery Connect) | X | 2X |
Аналитика, около 15 событий (реализация через один сервис, например, Amplitude) | X | 1,4X |
Значение Х — время на тестирование Android с Google-сервисами. Оценка Y*X — время на тестирование Android с двумя видами сервисов, где Y — коэффициент увеличения времени на работу с Huawei с HMS-сервисами
Все временные оценки — исходя из нашего опыта. Приводим их для примерного понимания.
Что хотелось бы сказать в конце...
Мы в Surf поддерживаем устройства Huawei без Google-сервисов на некоторых проектах и довольны процессами. Конечно, поработать головой иногда приходится чуть дольше: разработчикам — чтобы найти универсальное решение. QA — чтобы найти максимальное количество дефектов, широко покрыть фичи проверками и обеспечить качественное тестирование. И на мой взгляд, оно того стоит.
