Мобильная экосистема Huawei Mobile Services продолжает расти, и в этой статье мы попросили поделиться опытом и рассказать свои впечатления о работе с платформой мобильных разработчиков из «Лаборатории Касперского». Под катом то, как они адаптировали свои приложения, какие инструменты использовали и что получили в итоге.
Привет, Хабр! Меня зовут Виктор Яблоков (viktoryablokov), я руководитель управления разработки мобильных продуктов в «Лаборатории Касперского». Мы знакомы с экосистемой Huawei уже два года и за это время узнали её достаточно хорошо. Надеемся, что наши советы будут полезны всем командам, которые ещё не успели интегрировать поддержку HMS Core и выложить свои приложения в AppGallery.
Ресурсы любой, даже самой большой компании, ограниченны, и перед руководителями стоит непростой выбор, в какие новые инициативы их инвестировать, — идей и возможностей всегда гораздо больше, чем ресурсов. В «Лаборатории Касперского» мы строим свою стратегию развития продуктов на основе аналитики, экспериментов, валидируем востребованность новшеств путём снятия обратной связи с рынка. Так произошло и с поддержкой экосистемы Huawei в наших мобильных продуктах. Решение о интеграции HMS мы принимали в три этапа:
Мы несколько лет внимательно следили за всеми новшествами от компании Huawei и в 2018 году с появлением магазина приложений AppGallery решили «пощупать его», выложив туда наш флагманский продукт Kaspersky Internet Security для Android (KISA). На первом этапе он ничем не отличался от версии, выкладываемой в Google Play, и мы тестировали сам канал распространения. Два года назад у Huawei ещё не было такой развитой экосистемы, как сейчас, и подавляющее большинство установок приложений на Android-устройства Huawei осуществлялись из Google Play, а не из AppGallery. Эксперимент это подтвердил, и мы не стали сразу публиковать в AppGallery другие наши продукты, но продолжили сбор метрик и наблюдение за каналом.
Точкой роста экосистемы, по нашим наблюдениям, стало появление в 2018 году HMS Core, который за два года совершил колоссальный рывок и на текущий момент содержит 56 китов и позволяет решать все нужные нам задачи. С развитием HMS и появлением на рынке устройств, поддерживающих их, а также имеющих на борту в качестве основного магазина приложений AppGallery, мы в начале 2020 года увидели рост интереса к нашим продуктам и всерьёз задумались о поддержке HMS.
Мы систематически работаем с обратной связью от наших пользователей и заметили, что с весны 2020 года начался постепенный рост обращений от наших лояльных пользователей, приобретающих новые Huawei-устройства без Google Play Services и не нашедших наши продукты в AppGallery. Мы очень чутко прислушиваемся к мнению наших пользователей и больше ждать не могли — к концу мая 2020 все наши основные приложения были выложены в AppGallery и мы начали поэтапно переходить на HMS Core, добавляя в продукты новые возможности, предоставляемые экосистемой.
Итак, теперь вы понимаете логику принятия решения. Время перейти к следующему блоку, который, на наш взгляд, поможет проектным и продуктовым менеджерам правильно выстроить работу по интеграции в экосистему Huawei.
Наше управление уже много лет активно использует различные Agile-практики в процессах разработки. Многие из вас знают, что их десятки и список постоянно растёт. Каждая команда в зависимости от её размеров, стоящих задач, предпочтений ребят выбирает себе своё подмножество практик. При этом есть три столпа Agile, которые используются всеми: итеративность, инкрементальные поставки, приоритизация на основе user valuе с учётом технических рисков. Они много раз доказывали свою полезность и помогли нам с поддержкой HMS. Расскажем на примере одного из продуктов, как выглядел процесс разработки глазами руководителя проекта.
Итак, стратегическое решение принято: нам нужна поддержка HMS. Выбран и первый продукт, который должен заработать на HMS-only-устройствах. Мы решили, что это будет самый популярный мобильный продукт «Лаборатории Касперского» — Kaspersky Internet Security для Android (KISA). С чего начинаем? Ответ очевиден: нужно определиться с тем, что вообще означает «поддержать HMS» (другими словами, понять скоуп проекта), далее прикинуть стоимость и понять, когда мы достигнем цели. Со скоупом делаем простое предположение: если мы добьемся работы всего текущего функционала продукта на HMS, то все будут счастливы. Пусть это будет первая версия скоупа. Попробуем теперь подсчитать трудоёмкость реализации. Для этого, казалось бы, нужно в первую очередь познакомиться с возможностями новой платформы и выяснить, достаточно ли их для поддержки всего нашего продуктового функционала. Но мы не спешим отправлять разработчика изучать API. Наше управление на постоянной основе отслеживает все значимые тренды в мобильной разработке, занимаются этим разработчики. Результаты этих исследований мы фиксируем в кратких отчётах и храним в нашей базе исследований. Делаем предположение: мы явно не могли пропустить появление HMS в конце 2018 года. Смотрим, есть ли что-то у нас на эту тему. Точно, есть отчёт! В нём описание возможностей API и оценка готовности к поддержке HMS по каждому продукту в виде списка фич, которые не заработают без доработок на HMS, и фич, которые должны «взлететь» с минимальными изменениями или вообще as is. Неплохо, но прошло уже больше года с момента первого знакомства с HMS. Нужно актуализировать отчёт. Сделать это будет теперь намного проще, понятно, что именно нужно искать в документации с описанием ~13 000 API. Кстати, на недавно прошедшем Huawei Developers Day мы с удивлением узнали, что за два года количество API в HMS выросло с примерно 5 000 до почти 13 000. Кажется, это наглядный показатель серьёзности намерений Huawei в части развития HMS. Промежуточный итог после пары дней работы над проектом:
Можно переходить к следующем этапу. Если вы подумали, что это оценка, то ошиблись.
Прототипирование — ещё одна практика, которую мы активно используем, особенно когда дело касается больших и важных задач. Уровень неопределённости в сложных проектах на начальных стадиях настолько высок, что снять его исключительно тщательной проработкой требований если и возможно, то только в горизонте месяцев, что, конечно, абсолютно неприемлемо в сегодняшних реалиях. Поэтому мы делаем прототипы. Конкретно в описываемом проекте мы договариваемся взять текущую версию продукта и доработать её так, чтобы:
При этом исходим из того, что прототип, скорее всего, полностью выкинем в мусорку, поэтому не будем тратить время на все corner cases, не будем следовать всем нашим must have практикам в разработке типа unit tests. Цель следующая: выявить как можно больше технологических и процессных рисков за минимальное время. Ещё несколько дней работы, и всплывают следующие интересные детали:
Вот теперь уже можно значительно точнее подсчитать наши затраты и спланировать график работ с учётом привлечения сторонних команд. Делаем эту рутинную работу и назначаем встречу с руководителем продукта, который отвечает у нас за формирование и приоритизацию продуктового бэклога. Переходим к следующей стадии: приоритизируем фичи на основе их value с учётом имеющихся оценок и рисков, определяем график релизов.
Наверняка вы слышали и знаете, что означает эта аббревиатура. Ещё одна полезная практика, которая нам нравится. Наша цель — как можно раньше закрыть базовые потребности пользователя и получить фидбэк о продукте. Мы смотрим на результаты работы над прототипом, наши оценки и понимаем, что большую часть основных сценариев можно поддержать в течение месяца. Всех огорчает то, что в этот месяц никак не уложить поддержку In-App-покупок и функцию защиты от web-угроз в «родном» браузере Huawei (Web Protection). Принимаем решение: в первой версии выпускаем основные сценарии, а вместо In-Аpp-покупок предлагаем опцию покупки через наш сайт. На вторую версию оставляем In-App-покупки и Web Protection. План готов. Приступаем к разработке. И, конечно, на этапе разработки всплыло ещё много всего интересного и познавательного, об этом подробно написано в следующем разделе, отмечу только, что у нас появился в списке релизов ещё один, третий. За те пару месяцев, что мы работали над первыми релизами, Huawei продолжал нас радовать новыми интересными возможностями, и после появления функции Face Reсognition мы добавили в продукт возможность разблокировки доступа к определённому приложению через распознавание лица.
На этапе анализа / оценивания:
Выпускайте функционал итеративно. При приоритизации придерживайтесь следующего плана:
Huawei предоставляет разработчикам возможность интегрировать большое количество сервисов, которые, по нашему опыту, имеют охват, не просто сравнимый по функционалу с конкурентами, но и местами превосходящий их.
В первую очередь мы советуем вам присмотреться к HMS Toolkit:
1. Если у вас есть продукт, который уже использует сервисы от Google, то вам пригодится автоматический конвертер, который для многих сервисов поддерживает не просто замену сервисов Google на сервисы Huawei, но и генерацию кода для использования и сервисов Huawei, и сервисов от Google одновременно.
2. Даже если вы пишете приложение с нуля, HMS Toolkit поможет упростить процесс интеграции сервисов.
Помимо документации однозначно стоит пользоваться codelabs. Там приводят примеры пошаговой интеграции разных сервисов с чистого листа.
Далее рассмотрим сервисы, с которыми у нас есть опыт интеграции.
Сервис In-App-покупок от Huawei поддерживает подписки и одноразовые покупки, есть возможность регулировать цену и валюту оплаты. С точки зрения интеграции функционально API очень похож по возможностям на сервис In-App-покупок от Google, но есть ряд особенностей, которые повлияли на интеграцию в нашем случае:
Подобные возможности есть и у сервиса от Google, но с опцией отключения.
При работе с покупками в приложении есть возможность получить значительно больше информации о покупке, чем у того же Google. К примеру, можно легко узнать, находится пользователь сейчас в периоде бесплатного триала или нет (поле trialFlag).
Естественно, сервис от Huawei предоставляет и серверное API, которое можно использовать для дополнительной проверки покупок и получения всех событий, связанных с одноразовыми покупками и подписками (продление, смена вида подписки, отложенный платёж, ручное продление подписки пользователем и многое другое). Мы при интеграции серверного API проблем не наблюдали, в том числе потому, что API совместим по событиям и наборам данных с аналогичным API от Google, что сделало поддержку максимально простой.
Для тестирования есть возможность использовать тестовые аккаунты. Хотя на таких аккаунтах деньги при покупке не списываются, всё равно требуется наличие привязанного способа оплаты у аккаунта (у Google такого требования нет для тестовых аккаунтов).
Стоит ещё упомянуть, что Huawei достаточно прозрачно описывает политику передачи, хранения, обработки и удаления пользовательских данных. Явно рассматриваются вопросы безопасности и самого SDK. Это относится не только к сервису In-App-покупок, подобная информацию присутствует и для других сервисов Huawei.
Набор инструментов, предоставляемый в рамках Analytics Kit, однозначно можно считать более чем полноценным:
Например, можно проводить A/B-тестирование на определённых аудиториях или с помощью App Messaging предлагать определённой аудитории скидки, впоследствии анализируя результат при помощи Analytics Kit.
По итогу интеграция решения не составляет труда и даёт огромную отдачу в виде хорошо продуманных инструментов для анализа данных и таргетирования пользователей. Для большинства приложений продублировать функционал сервиса Google Analytics можлно в считаные минуты.
В наших продуктах используется лишь малая часть функций, предоставляемых сервисом Push Kit: мы используем сервис, чтобы отправить пуш из нашей инфраструктуры в приложение. Для этих нужд мы используем Data Messages — пуши, которые обрабатываются приложением без показа каких-либо нотификаций пользователю.
Поддерживаются и пуши, которые приведут к показу нотификации пользователю с произвольным содержимым и действием, что, в общем-то, будет знакомо с функциональной точки зрения всем пользователям Firebase Cloud Messaging. Что может показаться не так знакомо — необходимость запрашивать явное разрешение на использование части функций, например High-priority data messages позволяет запустить приложение в момент получении пуша, даже если оно не было запущено.
Есть возможность отправки сообщений с девайса на сервер, поддержка пушей в адаптивных сценариях (например, условие отправки — подключение наушников, когда на улице жарко и т. п.).
Интеграция на стороне приложения выглядит достаточно стандартно для пуш-сервисов — инициализируем сервис и получаем уникальный токен, а дальнейшая интеграция нужна только при необходимости использования отдельных возможностей, например обработки data messages.
Интеграция на серверной стороне в нашем случае не составила труда. Для отправки пуша требуется чуть больше идентификаторов, чем у Google, и поля самих пушей чуть иначе называются. В остальном проблем не возникало.
Crash Service мы не стали интегрировать в наши приложения по ряду причин:
На данный момент мы не нашли решения, позволяющего отслеживать ошибки ANR (Application Not Responding). Если поддержка отчётов по ANR появится в сервисе от Huawei, то мы однозначно рассмотрим опцию его подключения вместо Crashlytics.
Данный сервис мы используем для получения Open Advertising ID — это уникальный ID, который может быть сброшен пользователем в любой момент времени в системных настройках.
Среди других полезных функций данного сервиса можно выделить Install Referrer — он позволяет получить информацию из реферальной ссылки, которую использовал пользователь для установки приложения.
У Huawei есть устройства, например Huawei Mate 30 Pro, поддерживающие технологию 3D facial recognition, то есть распознавание по лицу. Судя по нашему опыту, стандартный BiometricPrompt не в состоянии использовать функцию распознавания по лицу на таких устройствах.
В нашем приложении Kaspersky Internet Security для Android мы интегрировали сервис LocalAuthentication Engine, чтобы позволить пользователям удобнее разблокировать приложения под защитой. При этом предоставляемый API позволил интегрировать эту возможность без лишних диалогов по сравнению с BiometricPrompt, тем самым улучшая UX.
Map Kit мы используем в продукте Kaspersky Safe Kids для отображения местоположения детей, на чьи устройства установлено приложение, а также для настройки безопасных периметров, при выходе из которых родителям придёт соответствующее оповещение.
Подключение Map Kit в консоли разработчика AppGallery происходит очень просто и описано в соответствующей пошаговой инструкции. Благодаря тому что API в Map Kit идентично аналогу от Google, знакомство с новым компонентом заняло очень мало времени. Со стороны команды разработки задача по интеграции новых карт свелась к тому, что мы вынесли в отдельный уровень абстракции все примитивы карт, которые у нас используются, а также сам компонент карт. После этого осталось только реализовать нужные классы и методы с использованием Map Kit API, добавить нужный Fragment в зависимости от того, карты какого поставщика мы хотим использовать в данный момент, и передать результат команде тестирования на проверку.
Для открытия магазина приложений можно использовать схему market://. Например, для приложения Kaspersky Internet Security: market://details?id=com.kms.free.
Такого рода универсальная ссылка позволяет открыть страницу конкретного приложения как в Google Play, так и в AppGallery. В особенности это может быть полезно для открытия Rate Us в магазине приложений или при рекламе других приложений.
Тестирование приложений на устройствах, поддерживающих только Huawei Mobile Services (далее HMS), во многом схоже с таковым на устройствах с сервисами Google, однако, конечно же, есть своя специфика.
Основываясь на опыте тестирования наших первых релизов для этого стора, хотелось бы обратить внимание на два направления:
Если вам приходилось тестировать аналитику Firebase от Google, в Huawei-аналитике вы увидите максимально похожий и интуитивно понятный инструмент.
Отправку событий аналитики из приложения можно проверить через консоль отладки, для этого нужно:
1. В консоли AppGallery Connect перейти в раздел My project и выбрать проект, соответствующий вашему приложению.
2. В левой колонке выбрать App debugging.
3. На устройстве выполнить команду adb shell setprop debug.huawei.hms.analytics.app <app.package.name>.
Результат: в App debugging в режиме реального времени будут отображаться события аналитики из приложения.
Покупки на HMS схожи с реализацией от Google. Пользователь оформляет подписку в приложении, HMS выписывают ордер о покупке, в приложении активируется подписка. Далее она продляется в аккаунте пользователя и в продукте. С точки зрения тестирования важно не допустить рассинхронизации этих двух процессов.
В HMS есть возможности покупки и управления подписками через аккаунт Huawei, о которых было написано выше. На них следует обратить особое внимание при разработке и тестировании, чтобы избежать рисков, когда подписка будет активна в аккаунте Huawei, а приложение при этом будет оставаться без лицензии.
Во всех случаях HMS должен нотифицировать приложение об изменении состояния подписки, а оно, в свою очередь, применять это состояние. Если у вас существует внутренняя инфраструктура, которая обрабатывает Huawei In-App нотификации, нужно проверять трехстороннюю интеграцию: приложение <-> HMS <-> внутренняя инфраструктура <-> приложение.
Ниже кратко о том, как проверить тестовые покупки:
1. на HMS-устройстве создать аккаунт Huawei;
2. в консоли AppGallery Connect перейти в раздел Users and permissions;
3. перейти в Test accounts и добавить созданный ранее аккаунт как тестовый Sandbox;
4. в аккаунте на устройстве добавить средство оплаты (деньги с него не спишут);
5. в приложении инициировать покупку -> появится сообщение:
6. нажать ОК и завершить процесс покупки.
Результат: в аккаунте Huawei будет активная подписка в статусе «продляется», далее нужно проверять продление (например, подписка на месяц продлевается каждые 5 минут), приостановку и отмену подписки.
В целом Huawei дает достаточно информации о подписке и её атрибутах, которые можно вывести в лог и которые позволяют достаточно легко идентифицировать проблему в процессе тестирования.
Инструменты проверки пуш-нотификаций так же, как и аналитика, имеют много общего с Firebase. Это пошло им только в плюс, при этом при отладке, о которой будет написано ниже, не возникает задержек с отправкой событий.
Можно отправить push напрямую через AppGallery-консоль, что может быть полезно, когда работа на бэкенде ещё не завершена, а в приложении готова первичная реализация и нужно проверить отправку пушей без готовности инфраструктуры. Для этого потребуется push token:
1. в консоли AppGallery Connect перейти в раздел My apps;
2. открыть вкладку Operate, в левой колонке выбрать Push Kit;
3. нажать Add notification;
4. выбрать тип Notification message и заполнить обязательные поля;
5. нажать Test effect;
6.ввести push token и нажать OK.
Результат: на HMS-устройстве будет получена нотификация с указанными параметрами:
После реализации backend-части Push Kit нужно как минимум проверять, что приложение не «отваливается» от backend по таймауту. Также следует проверить отправку пушей в doze mode.
Ввести девайс в doze:
Через некоторое время после активации (обычно полчаса, час) проверить работу Push Kit в интеграции с бэкендом. High priority нотификации должны работать.
Huawei предоставляет интересную и весьма полезную возможность провести NFT (Non Functional Testing) силами своего сервиса.Хорошая практика — запускать эти тесты время от времени, ну а для релиз-кандидатов (RC), по нашему мнению, это должно быть обязательной проверкой.
Кратко о том, как запустить тесты:
1. В консоли AppGallery Connect перейти в раздел My project и выбрать проект, соответствующий вашему приложению.
2. В левой колонке в разделе Quality выбрать Cloud testing.
3. Загрузить на сервис APK-файл вашего приложения.
4. Нажать New test.
Доступны следующие виды тестов:
Для полноценного выпуска релиза было необходимо проверить работу продуктов на реальных устройствах.У нас довольно большой пул тестовых устройств, однако HMS Only на тот момент была буквально пара штук, что для полноценного тестирования было, конечно, маловато.
Тут нас спасла собственная ферма (на основе OpenSTF), которая давала возможность шарить устройство для удалённого доступа, а также песочница с удалёнными HMS-устройствами, доступная в AppGallery, — Cloud debugging.
Этот сервис дает возможность удалённо использовать реальные устройства Huawei. Доступны все основные модели, есть возможность использовать несколько устройств одновременно, но обратите внимание, что время использования (резервирование) ограниченно.
Cloud debugging так же, как и Cloud testing, находится в разделе Quality.
Инструмент, несомненно, полезен в качестве предрелизной проверки во избежание проблем, которые могут возникнуть с выкладкой в стор. Находится в разделе Quality. Отчёт о проверке выглядит следующим образом:
В целом Huawei предоставляет простые, прозрачные и удобные инструменты для тестирования.
Мы освоили ещё не все возможности, но работаем над этим. Готовимся интегрировать Crash SDK и APM SDK, с нетерпением ждём появления Open Testing (аналога закрытого бета-тестирования).
В «Лаборатории Касперского» мы стараемся избегать ручного выполнения рутинных действий и вкладываемся в автоматизацию повторяющихся операций. Один из таких процессов — публикация обновлений наших продуктов в магазины приложений. Все наши процессы строятся на базе Azure DevOps Server (aka TFS), и публикация релизов не исключение. У нас уже несколько лет существует пайплайн для публикации приложений, который мы всячески дополняем и развиваем.
Чтобы поддержать публикацию в Huawei AppGallery, нам нужно было лишь добавить ещё одну среду для публикации. Реализация публикации в новую среду представляет собой последовательное выполнение шагов (задач) для публикации. Каждый шаг — это небольшой плагин для TFS, написанный, как правило, на TypeScript, и принимающий на вход параметры, необходимые для этой задачи.
В нашем случае нужно было реализовать новые шаги:
1) загрузить новое приложение (файл APK) и обновления для витрины (тексты) в AppGallery;
2) отправить новую версию на ревью.
Само API описано на портале для разработчиков с примерами на Java. Поддержка автоматической публикации продуктов в Huawei AppGallery была похожа на аналогичную задачу для Google Play и не вызвала у нас сложностей.
Стоит отметить, что на данный момент не поддерживается публикация нескольких APK-файлов (либо мы не нашли упоминание об этой возможности в документации), поэтому итоговый размер приложения для пользователя получается несколько больше, чем он мог бы быть.
Совет: не тяните, подключайте автоматическую публикацию новых версий ваших приложений в AppGallery сразу, чтобы ваши пользователи получали свежие версии ваших продуктов.
Мы однозначно можем рекомендовать к интеграции сервис Analytics Kit. Это позволит проще анализировать поведение пользователей, а с помощью функционала A/B-тестов можно проверять гипотезы по дальнейшему развитию приложения.
Магазин AppGallery находится в фазе активного набора пользователей, и компания Huawei заинтересована в продвижении зарекомендовавших себя приложений в магазине и помогает разработчикам в этом. Мы также это чувствуем на себе и благодарны Huawei за помощь.
2. Мы получали awareness пользователей за счёт размещения информации о нас как о партнере на landing-страницах новых смартфонов Huawei.
3. Мы участвовали в маркетинговых акциях с розыгрышем призов от Huawei, привлекали новых пользователей Huawei подарками: трёхмесячным триалом и дополнительными бонусами.
Также нельзя не отметить, что на начальном этапе развития экосистемы Huawei предоставлял разработчикам ещё большие преференции, например при регистрации аккаунта в AppGallery до конца июня 2020 года в течение первого года давалась нулевая комиссия на покупки в приложениях и всего 15 % для игр.
У нас были определённые прогнозы по росту нашей пользовательской базы, и на текущий момент они оправдываются, по некоторым продуктам мы растём даже заметно лучше прогнозов.
Обусловлено это, в частности, и тем, что наши коллеги из компании Huawei помогают разработчикам не только в поддержке HMS, но и в продвижении продуктов. Это своего рода синергия — от плотного и плодотворного сотрудничества выигрывают все.
Чтобы не быть голословными, приведём некоторые цифры: на момент написания статьи наш флагманский продукт Kaspersky Internet Security для Android имел уже больше 5 млн установок.
Не менее радуют и недавно выложенные в AppGallery продукты, например Kaspersky Who Calls за 4 месяца набрал 143 000 инсталляций в Российской Федерации.
Неплохие результаты, согласитесь, но все основные бенефиты ещё впереди. Темпы роста количества устройств Huawei, в которых основным магазином приложений является AppGallery, с каждым месяцем заметно увеличиваются, а вместе с этим растёт и интерес к нашим продуктам.
Привет, Хабр! Меня зовут Виктор Яблоков (viktoryablokov), я руководитель управления разработки мобильных продуктов в «Лаборатории Касперского». Мы знакомы с экосистемой Huawei уже два года и за это время узнали её достаточно хорошо. Надеемся, что наши советы будут полезны всем командам, которые ещё не успели интегрировать поддержку HMS Core и выложить свои приложения в AppGallery.
Под ссылкой видео нашего доклада с Huawei Developer Day, а ниже я дополню его советами по работе с платформой.
Три этапа интеграции в экосистему Huawei
Ресурсы любой, даже самой большой компании, ограниченны, и перед руководителями стоит непростой выбор, в какие новые инициативы их инвестировать, — идей и возможностей всегда гораздо больше, чем ресурсов. В «Лаборатории Касперского» мы строим свою стратегию развития продуктов на основе аналитики, экспериментов, валидируем востребованность новшеств путём снятия обратной связи с рынка. Так произошло и с поддержкой экосистемы Huawei в наших мобильных продуктах. Решение о интеграции HMS мы принимали в три этапа:
Этап № 1: Пилотная выкладка Kaspersky Internet Security для Android в AppGallery
Мы несколько лет внимательно следили за всеми новшествами от компании Huawei и в 2018 году с появлением магазина приложений AppGallery решили «пощупать его», выложив туда наш флагманский продукт Kaspersky Internet Security для Android (KISA). На первом этапе он ничем не отличался от версии, выкладываемой в Google Play, и мы тестировали сам канал распространения. Два года назад у Huawei ещё не было такой развитой экосистемы, как сейчас, и подавляющее большинство установок приложений на Android-устройства Huawei осуществлялись из Google Play, а не из AppGallery. Эксперимент это подтвердил, и мы не стали сразу публиковать в AppGallery другие наши продукты, но продолжили сбор метрик и наблюдение за каналом.
Этап № 2: Появление HMS Core
Точкой роста экосистемы, по нашим наблюдениям, стало появление в 2018 году HMS Core, который за два года совершил колоссальный рывок и на текущий момент содержит 56 китов и позволяет решать все нужные нам задачи. С развитием HMS и появлением на рынке устройств, поддерживающих их, а также имеющих на борту в качестве основного магазина приложений AppGallery, мы в начале 2020 года увидели рост интереса к нашим продуктам и всерьёз задумались о поддержке HMS.
Этап № 3: Рост популярности HMS Core
Мы систематически работаем с обратной связью от наших пользователей и заметили, что с весны 2020 года начался постепенный рост обращений от наших лояльных пользователей, приобретающих новые Huawei-устройства без Google Play Services и не нашедших наши продукты в AppGallery. Мы очень чутко прислушиваемся к мнению наших пользователей и больше ждать не могли — к концу мая 2020 все наши основные приложения были выложены в AppGallery и мы начали поэтапно переходить на HMS Core, добавляя в продукты новые возможности, предоставляемые экосистемой.
Итак, теперь вы понимаете логику принятия решения. Время перейти к следующему блоку, который, на наш взгляд, поможет проектным и продуктовым менеджерам правильно выстроить работу по интеграции в экосистему Huawei.
Как правильно выстроить работу
Наше управление уже много лет активно использует различные Agile-практики в процессах разработки. Многие из вас знают, что их десятки и список постоянно растёт. Каждая команда в зависимости от её размеров, стоящих задач, предпочтений ребят выбирает себе своё подмножество практик. При этом есть три столпа Agile, которые используются всеми: итеративность, инкрементальные поставки, приоритизация на основе user valuе с учётом технических рисков. Они много раз доказывали свою полезность и помогли нам с поддержкой HMS. Расскажем на примере одного из продуктов, как выглядел процесс разработки глазами руководителя проекта.
Итак, стратегическое решение принято: нам нужна поддержка HMS. Выбран и первый продукт, который должен заработать на HMS-only-устройствах. Мы решили, что это будет самый популярный мобильный продукт «Лаборатории Касперского» — Kaspersky Internet Security для Android (KISA). С чего начинаем? Ответ очевиден: нужно определиться с тем, что вообще означает «поддержать HMS» (другими словами, понять скоуп проекта), далее прикинуть стоимость и понять, когда мы достигнем цели. Со скоупом делаем простое предположение: если мы добьемся работы всего текущего функционала продукта на HMS, то все будут счастливы. Пусть это будет первая версия скоупа. Попробуем теперь подсчитать трудоёмкость реализации. Для этого, казалось бы, нужно в первую очередь познакомиться с возможностями новой платформы и выяснить, достаточно ли их для поддержки всего нашего продуктового функционала. Но мы не спешим отправлять разработчика изучать API. Наше управление на постоянной основе отслеживает все значимые тренды в мобильной разработке, занимаются этим разработчики. Результаты этих исследований мы фиксируем в кратких отчётах и храним в нашей базе исследований. Делаем предположение: мы явно не могли пропустить появление HMS в конце 2018 года. Смотрим, есть ли что-то у нас на эту тему. Точно, есть отчёт! В нём описание возможностей API и оценка готовности к поддержке HMS по каждому продукту в виде списка фич, которые не заработают без доработок на HMS, и фич, которые должны «взлететь» с минимальными изменениями или вообще as is. Неплохо, но прошло уже больше года с момента первого знакомства с HMS. Нужно актуализировать отчёт. Сделать это будет теперь намного проще, понятно, что именно нужно искать в документации с описанием ~13 000 API. Кстати, на недавно прошедшем Huawei Developers Day мы с удивлением узнали, что за два года количество API в HMS выросло с примерно 5 000 до почти 13 000. Кажется, это наглядный показатель серьёзности намерений Huawei в части развития HMS. Промежуточный итог после пары дней работы над проектом:
- мы понимаем, какие части продукта точно потребуют доработок;
- нам придётся серьёзно вложиться в поддержку In-App-покупок. В процессе актуализации отчёта мы обнаруживаем, что компонент покупок внутри приложения (In-App Kit) стал намного функциональнее и предоставляет массу возможностей для монетизации продукта.
Можно переходить к следующем этапу. Если вы подумали, что это оценка, то ошиблись.
Прототипирование — ещё одна практика, которую мы активно используем, особенно когда дело касается больших и важных задач. Уровень неопределённости в сложных проектах на начальных стадиях настолько высок, что снять его исключительно тщательной проработкой требований если и возможно, то только в горизонте месяцев, что, конечно, абсолютно неприемлемо в сегодняшних реалиях. Поэтому мы делаем прототипы. Конкретно в описываемом проекте мы договариваемся взять текущую версию продукта и доработать её так, чтобы:
- она для начала запустилась на реальном HMS-only-устройстве;
- далее с помощью QA быстро смотрим основные сценарии, фиксируем, что не работает;
- пытаемся заставить работать то, что отломалось.
При этом исходим из того, что прототип, скорее всего, полностью выкинем в мусорку, поэтому не будем тратить время на все corner cases, не будем следовать всем нашим must have практикам в разработке типа unit tests. Цель следующая: выявить как можно больше технологических и процессных рисков за минимальное время. Ещё несколько дней работы, и всплывают следующие интересные детали:
- интеграция сервиса In-App-покупок потребует доработок на стороне нашей инфраструктуры из-за ряда действий, которых пользователь может выполнить вне приложения (подробнее о них — в разделе о сервисе In-App-покупок). Прототип был очень полезен в данном случае, так как анализ API не дал нам явного понимания, что у пользователя есть больше возможностей по управлению подпиской вне приложения, чем у уже нами используемого решения от Google;
- при работе с Push Kit выяснилось, что нужно запрашивать у Huawei права на использование некоторых возможностей (см. раздел о сервисе Push Kit), чтобы получить идентичное поведение сервису пушей от Google;
- мы ожидали, что все сервисы, завязанные на Google в том или ином виде, перестанут работать. На деле выяснилось, что Crashlytics и AppsFlyer работали без дополнительных доработок с нашей стороны на устройствах без сервисов Google. При этом AppsFlyer даже явно поддерживает работу с сервисами Huawei, хотя и не на 100 % (мы не нашли способа сохранить аналитику об удалении продукта).
Вот теперь уже можно значительно точнее подсчитать наши затраты и спланировать график работ с учётом привлечения сторонних команд. Делаем эту рутинную работу и назначаем встречу с руководителем продукта, который отвечает у нас за формирование и приоритизацию продуктового бэклога. Переходим к следующей стадии: приоритизируем фичи на основе их value с учётом имеющихся оценок и рисков, определяем график релизов.
Minimum Viable Product, или MVP
Наверняка вы слышали и знаете, что означает эта аббревиатура. Ещё одна полезная практика, которая нам нравится. Наша цель — как можно раньше закрыть базовые потребности пользователя и получить фидбэк о продукте. Мы смотрим на результаты работы над прототипом, наши оценки и понимаем, что большую часть основных сценариев можно поддержать в течение месяца. Всех огорчает то, что в этот месяц никак не уложить поддержку In-App-покупок и функцию защиты от web-угроз в «родном» браузере Huawei (Web Protection). Принимаем решение: в первой версии выпускаем основные сценарии, а вместо In-Аpp-покупок предлагаем опцию покупки через наш сайт. На вторую версию оставляем In-App-покупки и Web Protection. План готов. Приступаем к разработке. И, конечно, на этапе разработки всплыло ещё много всего интересного и познавательного, об этом подробно написано в следующем разделе, отмечу только, что у нас появился в списке релизов ещё один, третий. За те пару месяцев, что мы работали над первыми релизами, Huawei продолжал нас радовать новыми интересными возможностями, и после появления функции Face Reсognition мы добавили в продукт возможность разблокировки доступа к определённому приложению через распознавание лица.
Подытожим советами для менеджеров
На этапе анализа / оценивания:
- воспользуйтесь вот этой статьёй, вы получите точное представление, с каким вашим функционалом могут быть проблемы;
- сделайте прототип, попробуйте «заставить» заработать все основные сценарии;
- дочитайте эту статью до конца, ниже много полезного, что сэкономит вам много времени.
Выпускайте функционал итеративно. При приоритизации придерживайтесь следующего плана:
- сначала базовый функционал + аналитика;
- дальше поддержка других важных для вас Kit;
- следите за развитием HMS — вполне вероятно, что у вас появятся ещё идеи в результате появления новых фич.
Советы разработчикам
Huawei предоставляет разработчикам возможность интегрировать большое количество сервисов, которые, по нашему опыту, имеют охват, не просто сравнимый по функционалу с конкурентами, но и местами превосходящий их.
В первую очередь мы советуем вам присмотреться к HMS Toolkit:
1. Если у вас есть продукт, который уже использует сервисы от Google, то вам пригодится автоматический конвертер, который для многих сервисов поддерживает не просто замену сервисов Google на сервисы Huawei, но и генерацию кода для использования и сервисов Huawei, и сервисов от Google одновременно.
2. Даже если вы пишете приложение с нуля, HMS Toolkit поможет упростить процесс интеграции сервисов.
Помимо документации однозначно стоит пользоваться codelabs. Там приводят примеры пошаговой интеграции разных сервисов с чистого листа.
Далее рассмотрим сервисы, с которыми у нас есть опыт интеграции.
In-App-покупки
Сервис In-App-покупок от Huawei поддерживает подписки и одноразовые покупки, есть возможность регулировать цену и валюту оплаты. С точки зрения интеграции функционально API очень похож по возможностям на сервис In-App-покупок от Google, но есть ряд особенностей, которые повлияли на интеграцию в нашем случае:
- пользователь может возобновить подписку вне приложения;
- есть возможность переключиться между подписками (например, с месячной на годовую) вне приложения;
- существует возможность отложить предстоящий платёж на определённый срок.
Подобные возможности есть и у сервиса от Google, но с опцией отключения.
При работе с покупками в приложении есть возможность получить значительно больше информации о покупке, чем у того же Google. К примеру, можно легко узнать, находится пользователь сейчас в периоде бесплатного триала или нет (поле trialFlag).
Естественно, сервис от Huawei предоставляет и серверное API, которое можно использовать для дополнительной проверки покупок и получения всех событий, связанных с одноразовыми покупками и подписками (продление, смена вида подписки, отложенный платёж, ручное продление подписки пользователем и многое другое). Мы при интеграции серверного API проблем не наблюдали, в том числе потому, что API совместим по событиям и наборам данных с аналогичным API от Google, что сделало поддержку максимально простой.
Для тестирования есть возможность использовать тестовые аккаунты. Хотя на таких аккаунтах деньги при покупке не списываются, всё равно требуется наличие привязанного способа оплаты у аккаунта (у Google такого требования нет для тестовых аккаунтов).
Стоит ещё упомянуть, что Huawei достаточно прозрачно описывает политику передачи, хранения, обработки и удаления пользовательских данных. Явно рассматриваются вопросы безопасности и самого SDK. Это относится не только к сервису In-App-покупок, подобная информацию присутствует и для других сервисов Huawei.
Analytics Kit
Набор инструментов, предоставляемый в рамках Analytics Kit, однозначно можно считать более чем полноценным:
- поддерживаются события и пользовательские атрибуты;
- часть событий и атрибутов собираются автоматически;
- есть возможность экспорта данных для анализа в сторонних BI (Business intelligence) системах;
- можно отслеживать события в реальном времени;
- даже без использования сторонних BI-решений Huawei предоставляет большое количество инструментов для анализа полученной аналитики:
- аналитика не только даёт средства для проведения качественного анализа данных, но и работает как поставщик данных для таргетирования пользователей при использовании других сервисов:
Например, можно проводить A/B-тестирование на определённых аудиториях или с помощью App Messaging предлагать определённой аудитории скидки, впоследствии анализируя результат при помощи Analytics Kit.
По итогу интеграция решения не составляет труда и даёт огромную отдачу в виде хорошо продуманных инструментов для анализа данных и таргетирования пользователей. Для большинства приложений продублировать функционал сервиса Google Analytics можлно в считаные минуты.
Push Kit
В наших продуктах используется лишь малая часть функций, предоставляемых сервисом Push Kit: мы используем сервис, чтобы отправить пуш из нашей инфраструктуры в приложение. Для этих нужд мы используем Data Messages — пуши, которые обрабатываются приложением без показа каких-либо нотификаций пользователю.
Поддерживаются и пуши, которые приведут к показу нотификации пользователю с произвольным содержимым и действием, что, в общем-то, будет знакомо с функциональной точки зрения всем пользователям Firebase Cloud Messaging. Что может показаться не так знакомо — необходимость запрашивать явное разрешение на использование части функций, например High-priority data messages позволяет запустить приложение в момент получении пуша, даже если оно не было запущено.
Есть возможность отправки сообщений с девайса на сервер, поддержка пушей в адаптивных сценариях (например, условие отправки — подключение наушников, когда на улице жарко и т. п.).
Интеграция на стороне приложения выглядит достаточно стандартно для пуш-сервисов — инициализируем сервис и получаем уникальный токен, а дальнейшая интеграция нужна только при необходимости использования отдельных возможностей, например обработки data messages.
Интеграция на серверной стороне в нашем случае не составила труда. Для отправки пуша требуется чуть больше идентификаторов, чем у Google, и поля самих пушей чуть иначе называются. В остальном проблем не возникало.
Crash Service
Crash Service мы не стали интегрировать в наши приложения по ряду причин:
- сервис ещё не был готов к использованию в момент поиска решения;
- мы на практике выяснили, что Firebase Crashlytics вполне работает без сервисов Google. Важно понимать, что далеко не все сервисы, которые уже используются в вашем приложении, необходимо будет заменять при желании поддержать устройства без сервисов Google. Обязательно обратите внимание на информацию о необходимости сервисов Google для функционирования различных библиотек.
На данный момент мы не нашли решения, позволяющего отслеживать ошибки ANR (Application Not Responding). Если поддержка отчётов по ANR появится в сервисе от Huawei, то мы однозначно рассмотрим опцию его подключения вместо Crashlytics.
Ads Kit
Данный сервис мы используем для получения Open Advertising ID — это уникальный ID, который может быть сброшен пользователем в любой момент времени в системных настройках.
Среди других полезных функций данного сервиса можно выделить Install Referrer — он позволяет получить информацию из реферальной ссылки, которую использовал пользователь для установки приложения.
Face Recognition
У Huawei есть устройства, например Huawei Mate 30 Pro, поддерживающие технологию 3D facial recognition, то есть распознавание по лицу. Судя по нашему опыту, стандартный BiometricPrompt не в состоянии использовать функцию распознавания по лицу на таких устройствах.
В нашем приложении Kaspersky Internet Security для Android мы интегрировали сервис LocalAuthentication Engine, чтобы позволить пользователям удобнее разблокировать приложения под защитой. При этом предоставляемый API позволил интегрировать эту возможность без лишних диалогов по сравнению с BiometricPrompt, тем самым улучшая UX.
Map Kit
Map Kit мы используем в продукте Kaspersky Safe Kids для отображения местоположения детей, на чьи устройства установлено приложение, а также для настройки безопасных периметров, при выходе из которых родителям придёт соответствующее оповещение.
Подключение Map Kit в консоли разработчика AppGallery происходит очень просто и описано в соответствующей пошаговой инструкции. Благодаря тому что API в Map Kit идентично аналогу от Google, знакомство с новым компонентом заняло очень мало времени. Со стороны команды разработки задача по интеграции новых карт свелась к тому, что мы вынесли в отдельный уровень абстракции все примитивы карт, которые у нас используются, а также сам компонент карт. После этого осталось только реализовать нужные классы и методы с использованием Map Kit API, добавить нужный Fragment в зависимости от того, карты какого поставщика мы хотим использовать в данный момент, и передать результат команде тестирования на проверку.
Ссылки на страницу приложения в магазине
Для открытия магазина приложений можно использовать схему market://. Например, для приложения Kaspersky Internet Security: market://details?id=com.kms.free.
Такого рода универсальная ссылка позволяет открыть страницу конкретного приложения как в Google Play, так и в AppGallery. В особенности это может быть полезно для открытия Rate Us в магазине приложений или при рекламе других приложений.
Советы тестировщикам
Тестирование приложений на устройствах, поддерживающих только Huawei Mobile Services (далее HMS), во многом схоже с таковым на устройствах с сервисами Google, однако, конечно же, есть своя специфика.
Основываясь на опыте тестирования наших первых релизов для этого стора, хотелось бы обратить внимание на два направления:
- интеграция с Kit's от Huawei, которые сменили соответствующие сервисы Google;
- использование инструментов тестирования, доступных в AppGallery Connect.
Интеграция с Huawei Kit's
Analytics Kit
Если вам приходилось тестировать аналитику Firebase от Google, в Huawei-аналитике вы увидите максимально похожий и интуитивно понятный инструмент.
Отправку событий аналитики из приложения можно проверить через консоль отладки, для этого нужно:
1. В консоли AppGallery Connect перейти в раздел My project и выбрать проект, соответствующий вашему приложению.
2. В левой колонке выбрать App debugging.
3. На устройстве выполнить команду adb shell setprop debug.huawei.hms.analytics.app <app.package.name>.
Результат: в App debugging в режиме реального времени будут отображаться события аналитики из приложения.
In-App purchases Kit
Покупки на HMS схожи с реализацией от Google. Пользователь оформляет подписку в приложении, HMS выписывают ордер о покупке, в приложении активируется подписка. Далее она продляется в аккаунте пользователя и в продукте. С точки зрения тестирования важно не допустить рассинхронизации этих двух процессов.
В HMS есть возможности покупки и управления подписками через аккаунт Huawei, о которых было написано выше. На них следует обратить особое внимание при разработке и тестировании, чтобы избежать рисков, когда подписка будет активна в аккаунте Huawei, а приложение при этом будет оставаться без лицензии.
Во всех случаях HMS должен нотифицировать приложение об изменении состояния подписки, а оно, в свою очередь, применять это состояние. Если у вас существует внутренняя инфраструктура, которая обрабатывает Huawei In-App нотификации, нужно проверять трехстороннюю интеграцию: приложение <-> HMS <-> внутренняя инфраструктура <-> приложение.
Ниже кратко о том, как проверить тестовые покупки:
1. на HMS-устройстве создать аккаунт Huawei;
2. в консоли AppGallery Connect перейти в раздел Users and permissions;
3. перейти в Test accounts и добавить созданный ранее аккаунт как тестовый Sandbox;
4. в аккаунте на устройстве добавить средство оплаты (деньги с него не спишут);
5. в приложении инициировать покупку -> появится сообщение:
6. нажать ОК и завершить процесс покупки.
Результат: в аккаунте Huawei будет активная подписка в статусе «продляется», далее нужно проверять продление (например, подписка на месяц продлевается каждые 5 минут), приостановку и отмену подписки.
В целом Huawei дает достаточно информации о подписке и её атрибутах, которые можно вывести в лог и которые позволяют достаточно легко идентифицировать проблему в процессе тестирования.
Push Kit
Инструменты проверки пуш-нотификаций так же, как и аналитика, имеют много общего с Firebase. Это пошло им только в плюс, при этом при отладке, о которой будет написано ниже, не возникает задержек с отправкой событий.
Можно отправить push напрямую через AppGallery-консоль, что может быть полезно, когда работа на бэкенде ещё не завершена, а в приложении готова первичная реализация и нужно проверить отправку пушей без готовности инфраструктуры. Для этого потребуется push token:
1. в консоли AppGallery Connect перейти в раздел My apps;
2. открыть вкладку Operate, в левой колонке выбрать Push Kit;
3. нажать Add notification;
4. выбрать тип Notification message и заполнить обязательные поля;
5. нажать Test effect;
6.ввести push token и нажать OK.
Результат: на HMS-устройстве будет получена нотификация с указанными параметрами:
После реализации backend-части Push Kit нужно как минимум проверять, что приложение не «отваливается» от backend по таймауту. Также следует проверить отправку пушей в doze mode.
Ввести девайс в doze:
- adb shell dumpsys deviceidle enable;
- adb shell dumpsys battery unplug;
- перевести устройство в спящий режим;
- adb shell dumpsys deviceidle step deep (выполнять до состояния IDLE).
Через некоторое время после активации (обычно полчаса, час) проверить работу Push Kit в интеграции с бэкендом. High priority нотификации должны работать.
Инструменты тестирования AppGallery Connect
Cloud Testing
Huawei предоставляет интересную и весьма полезную возможность провести NFT (Non Functional Testing) силами своего сервиса.Хорошая практика — запускать эти тесты время от времени, ну а для релиз-кандидатов (RC), по нашему мнению, это должно быть обязательной проверкой.
Кратко о том, как запустить тесты:
1. В консоли AppGallery Connect перейти в раздел My project и выбрать проект, соответствующий вашему приложению.
2. В левой колонке в разделе Quality выбрать Cloud testing.
3. Загрузить на сервис APK-файл вашего приложения.
4. Нажать New test.
Доступны следующие виды тестов:
- Compatibility test
- Stability test
- Performance test
- Power consumption test
Cloud Debugging
Для полноценного выпуска релиза было необходимо проверить работу продуктов на реальных устройствах.У нас довольно большой пул тестовых устройств, однако HMS Only на тот момент была буквально пара штук, что для полноценного тестирования было, конечно, маловато.
Тут нас спасла собственная ферма (на основе OpenSTF), которая давала возможность шарить устройство для удалённого доступа, а также песочница с удалёнными HMS-устройствами, доступная в AppGallery, — Cloud debugging.
Этот сервис дает возможность удалённо использовать реальные устройства Huawei. Доступны все основные модели, есть возможность использовать несколько устройств одновременно, но обратите внимание, что время использования (резервирование) ограниченно.
Cloud debugging так же, как и Cloud testing, находится в разделе Quality.
Integration Check
Инструмент, несомненно, полезен в качестве предрелизной проверки во избежание проблем, которые могут возникнуть с выкладкой в стор. Находится в разделе Quality. Отчёт о проверке выглядит следующим образом:
В целом Huawei предоставляет простые, прозрачные и удобные инструменты для тестирования.
Мы освоили ещё не все возможности, но работаем над этим. Готовимся интегрировать Crash SDK и APM SDK, с нетерпением ждём появления Open Testing (аналога закрытого бета-тестирования).
Советы релиз-инженерам
В «Лаборатории Касперского» мы стараемся избегать ручного выполнения рутинных действий и вкладываемся в автоматизацию повторяющихся операций. Один из таких процессов — публикация обновлений наших продуктов в магазины приложений. Все наши процессы строятся на базе Azure DevOps Server (aka TFS), и публикация релизов не исключение. У нас уже несколько лет существует пайплайн для публикации приложений, который мы всячески дополняем и развиваем.
Чтобы поддержать публикацию в Huawei AppGallery, нам нужно было лишь добавить ещё одну среду для публикации. Реализация публикации в новую среду представляет собой последовательное выполнение шагов (задач) для публикации. Каждый шаг — это небольшой плагин для TFS, написанный, как правило, на TypeScript, и принимающий на вход параметры, необходимые для этой задачи.
В нашем случае нужно было реализовать новые шаги:
1) загрузить новое приложение (файл APK) и обновления для витрины (тексты) в AppGallery;
2) отправить новую версию на ревью.
Само API описано на портале для разработчиков с примерами на Java. Поддержка автоматической публикации продуктов в Huawei AppGallery была похожа на аналогичную задачу для Google Play и не вызвала у нас сложностей.
Стоит отметить, что на данный момент не поддерживается публикация нескольких APK-файлов (либо мы не нашли упоминание об этой возможности в документации), поэтому итоговый размер приложения для пользователя получается несколько больше, чем он мог бы быть.
Совет: не тяните, подключайте автоматическую публикацию новых версий ваших приложений в AppGallery сразу, чтобы ваши пользователи получали свежие версии ваших продуктов.
Советы по продвижению
Мы однозначно можем рекомендовать к интеграции сервис Analytics Kit. Это позволит проще анализировать поведение пользователей, а с помощью функционала A/B-тестов можно проверять гипотезы по дальнейшему развитию приложения.
Магазин AppGallery находится в фазе активного набора пользователей, и компания Huawei заинтересована в продвижении зарекомендовавших себя приложений в магазине и помогает разработчикам в этом. Мы также это чувствуем на себе и благодарны Huawei за помощь.
- Наши приложения несколько раз получали фичеринг в магазине приложений, за счёт которого пользовательский трафик в наши приложения заметно вырос.
2. Мы получали awareness пользователей за счёт размещения информации о нас как о партнере на landing-страницах новых смартфонов Huawei.
3. Мы участвовали в маркетинговых акциях с розыгрышем призов от Huawei, привлекали новых пользователей Huawei подарками: трёхмесячным триалом и дополнительными бонусами.
Также нельзя не отметить, что на начальном этапе развития экосистемы Huawei предоставлял разработчикам ещё большие преференции, например при регистрации аккаунта в AppGallery до конца июня 2020 года в течение первого года давалась нулевая комиссия на покупки в приложениях и всего 15 % для игр.
Первые результаты
У нас были определённые прогнозы по росту нашей пользовательской базы, и на текущий момент они оправдываются, по некоторым продуктам мы растём даже заметно лучше прогнозов.
Обусловлено это, в частности, и тем, что наши коллеги из компании Huawei помогают разработчикам не только в поддержке HMS, но и в продвижении продуктов. Это своего рода синергия — от плотного и плодотворного сотрудничества выигрывают все.
Чтобы не быть голословными, приведём некоторые цифры: на момент написания статьи наш флагманский продукт Kaspersky Internet Security для Android имел уже больше 5 млн установок.
Не менее радуют и недавно выложенные в AppGallery продукты, например Kaspersky Who Calls за 4 месяца набрал 143 000 инсталляций в Российской Федерации.
Неплохие результаты, согласитесь, но все основные бенефиты ещё впереди. Темпы роста количества устройств Huawei, в которых основным магазином приложений является AppGallery, с каждым месяцем заметно увеличиваются, а вместе с этим растёт и интерес к нашим продуктам.