Как обеспечить качество приложения, оптимизированного для любых устройств, и опубликовать его в Google Play

Здравствуйте!

Спасибо, что присоединились к нам на этом занятии, посвященном качеству приложений, оптимизированных для любых устройств, и публикации в Google Play для устройств, отличных от мобильных.

Меня зовут Ян Кляйнерт, я инженер по связям с разработчиками в команде Android for Cars.

А я Фаустин Ляо, руководитель команды Google Play по обеспечению безопасности и доверия.

Мы очень рады, что вы сегодня с нами.

Поэтому в течение многих лет, когда мы говорили о разработке для Android, большинство из нас представляли себе только мобильное устройство, но экосистема Android расширилась далеко за пределы смартфонов.

Сегодня пользователи взаимодействуют с приложениями на устройствах в гостиной на Android TV, в машине на Android Auto или Automotive OS, на запястье с Wear OS и все чаще в иммерсивных 3D-пространствах с Android XR.

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

Процесс от создания приложения до его публикации в Google Play в целом остается таким же, как и для мобильных выпусков.

Создайте и подготовьте приложение, а затем опубликуйте его страницу в Play Console. Протестируйте приложение, загрузите и отправьте рабочую версию, а затем дождитесь проверки и одобрения.

Однако при публикации приложений для других типов устройств нужно учитывать некоторые особенности.

Сегодня мы расскажем, как подготовиться к выпуску приложения на разных устройствах, чтобы он прошел гладко и предсказуемо.

Начнем с основ: как спроектировать и упаковать приложение.

Поэтому, прежде чем вы начнете работать с Google Play Console, вам нужно принять важное архитектурное решение.

Вы создаете один унифицированный набор App Bundle, содержащий все необходимое для всех поддерживаемых типов устройств, или разбиваете приложение на модули для конкретных типов устройств и генерируете наборы Android App Bundle (AAB) для каждого из них?

Поэтому, когда я говорю о модулях или модульности, я имею в виду способ структурирования базы кода, который упрощает ее поддержку.

Существует множество подходов к модульности, но в целом вы организуете свою базу кода в слабо связанные, автономные части, где каждая часть является модулем.

Поэтому, хотя единый набор Android App Bundle может показаться более простым в управлении, мы рекомендуем использовать модульный подход.

Вот пример, который демонстрирует, почему мы рекомендуем этот модульный подход.

Представим, что у вас есть приложение, которое поддерживает и мобильные устройства, и Android TV.

Если вы отправите один набор Android App Bundle в стандартном типе версии для мобильных устройств и приложение для Android TV не пройдет проверку, выпуск будет остановлен.

Это повлияет на выпуск как приложения для Android TV, так и мобильного приложения.

Поэтому, даже если с мобильным приложением все в порядке, вам нужно устранить проблемы, из-за которых не удалось пройти проверку Android TV, и повторно отправить приложение на проверку, прежде чем выпуск станет доступен пользователям.

С другой стороны, модульные наборы App Bundle для каждого типа устройств позволят вам более точно управлять выпусками и отделять их от версий для мобильных устройств.

Если у вас есть отдельные модули для мобильного и ТВ-приложения, вы можете создать для каждого из них отдельный набор Android App Bundle.

Если при проверке ТВ-приложения возникнет проблема, то будет заблокирован только его выпуск.

Выпуск мобильного приложения будет опубликован, как и планировалось.

Как я уже говорил, существует множество подходов к модульности.

Вот пример подхода к модульной структуре приложения с аудиокнигами, которое работает на мобильных устройствах и в Android Automotive OS.

Вверху зеленым цветом обозначены модули приложений для каждого типа устройств. Это помогает разделить зависимости, связанные с платформой.

Желтым цветом выделены модули функций, которые соответствуют изолированным частям функциональности приложения.

Модули данных выделены синим цветом, а внизу у нас есть основные или общие модули, которые обычно используются для хранения кода, который часто используют другие модули.

Затем в файлах настроек Gradle вашего проекта вы можете включить и настроить эту многомодульную конфигурацию Gradle для поддержки такого рода модульности.

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

Поэтому вы будете использовать одно и то же название пакета или идентификатор приложения для каждого модуля и набора.

Этот модульный подход напрямую связан с вашей стратегией работы с типами версий в Play Console.

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

Для Android TV, Android XR и Android Automotive OS у вас есть выбор.

Вы можете публиковать их вместе с мобильными версиями или использовать отдельные типы версий для устройств.

Однако есть два исключения.

Для Wear OS необходимо использовать специальный тип версии.

Для Android Auto, который по сути является расширением мобильного приложения, проецируемым на экран автомобиля, единственным выбором является стандартный мобильный трек.

Если вы управляете несколькими типами версий, нумерация версий имеет критическое значение.

Один из подходов – назначить первые несколько цифр кода версии для типа устройства.

Например, 01 для мобильных устройств, 02 для Wear OS, 03 для Android Automotive OS и т. д.

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

Это поможет избежать конфликтов кодов версий в Play Console.

После упаковки приложения его нужно протестировать.

Разработка для разных типов устройств требует тщательного тестирования. Google Play предлагает три канала для тестирования перед выпуском рабочей версии: внутреннее, закрытое и открытое.

Если вы используете отдельные типы версий для разных типов устройств, то можете комбинировать их с типами версий для тестирования, чтобы получить ещё больше контроля над процессом.

Например, вы можете выпустить версию для закрытого тестирования мобильного приложения в стандартном типе версии и отдельную версию для закрытого тестирования приложения для Android TV в типе версии для Android TV. При желании для них можно назначить разные группы тестировщиков.

Поэтому внутреннее тестирование – отличная отправная точка.

Оно позволяет быстро распространить приложение среди тестировщиков (не более 100) и, что важно, не требует проверки Google Play.

Это значит, что вы и ваши тестировщики можете быстро устанавливать приложение на устройства и проверять его работу на эмуляторах или реальных телевизорах, часах и других устройствах.

Для внутренних тестов вы получите уникальный URL, которым сможете поделиться с тестировщиками.

Когда вы будете довольны результатами внутреннего тестирования, можно переходить к закрытому и открытому.

Вы можете расширить внутреннее тестирование, создав выпуск для закрытого тестирования. Это позволит проверить предварительные версии приложения на более широкой выборке тестировщиков и собрать более точные отзывы.

Управлять группами закрытого тестирования можно с помощью списков адресов электронной почты или Google Групп.

Открытое тестирование позволяет проверить приложение в большой группе пользователей, опубликовав его в Google Play.

Ваше приложение будет доступно в Google Play, и любой пользователь сможет присоединиться к программе открытого тестирования.

Приглашение не требуется. Тестировщики смогут оставлять отзывы о приложении, в том числе конфиденциальные.

Версии для открытого и закрытого тестирования проходят проверку.

Это на самом деле огромное преимущество.

Это позволит вам протестировать сам процесс проверки и устранить все препятствия задолго до долгожданного дня запуска.

Давайте поговорим о том, что представляет собой процесс проверки и почему он важен.

Все эти правила и рекомендации направлены на повышение качества приложений.

Они должны по максимуму задействовать возможности устройств премиум-класса, а также быть полезны, удобны и безопасны в использовании.

Давайте посмотрим, как подготовить приложение, чтобы оно прошло проверку без проблем.

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

Мы публикуем рекомендации по обеспечению качества основных приложений, которые применимы ко всем приложениям и определяют минимальное качество, которому должны соответствовать все приложения, а также рекомендации по обеспечению качества адаптивных приложений, и они помогут вам обеспечить отличное качество работы вашего приложения независимо от форм-фактора устройства, размера экрана или режима отображения.

Эти два набора рекомендаций вместе – действительно хорошее место для начала.

Но у нас также есть рекомендации по обеспечению качества приложений для каждого типа устройств.

Наши специалисты будут тестировать ваши приложения на реальных устройствах и эмуляторах, чтобы проверить, соблюдаются ли эти рекомендации.

Поэтому очень важно убедиться, что ваше приложение им соответствует.

Давайте рассмотрим самые распространенные причины, по которым приложения отклоняются для каждого типа устройств.

Однако помните, что это не полный список рекомендаций по обеспечению качества приложений.

Поэтому обязательно ознакомьтесь с рекомендациями по обеспечению качества для каждого форм-фактора, с которым вы работаете, чтобы получить более надежный набор критериев.

Начнем с Android TV.

Поэтому внизу слайдов с разделами вы увидите короткую ссылку, которая приведет вас к полному списку рекомендаций по обеспечению качества приложений для этого форм-фактора.

Одна из распространенных причин отклонения приложений для Android TV – отсутствие баннера для главного экрана на каждом из поддерживаемых языков.

Поэтому вам следует предоставить изображение размером 320 на 180 пикселей, которое включает локализованный текст, идентифицирующий ваше приложение.

На изображении на этом слайде показан пример баннера на главном экране, который соответствует этим критериям.

Во-вторых, на большинстве телевизоров пользователи будут взаимодействовать с устройством с помощью пульта дистанционного управления с крестовиной.

Поэтому очень важно правильно реализовать навигацию и фокус с помощью D-pad.

Убедитесь, что ваше приложение поддерживает хотя бы минимальный набор элементов управления d-pad, чтобы избежать отклонения по этому критерию.

Третья распространенная причина отклонения приложений для Android TV – отсутствие фильтра интентов CATEGORY_LEANBACK_LAUNCHER в файле манифеста Android.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

Этот фильтр позволяет Google Play идентифицировать ваше приложение как предназначенное для телевизоров и показывать его пользователям.

Когда пользователь выбирает ваше приложение на главном экране телевизора, это намерение определяет, какое действие нужно запустить.

Убедитесь, что вы добавили его в манифест.

Android XR – следующий шаг.

При создании приложений для XR-шлемов или XR-очков на базе Android XR особое внимание уделяйте производительности, рендерингу и стабильности.

Чтобы проверить, соблюдаются ли минимальные требования к частоте кадров, вы можете использовать Perfetto для профилирования производительности приложений, созданных с помощью Jetpack XR SDK.

Если вы используете движок реального времени, например Unity, то можете задействовать встроенные инструменты профилирования, чтобы убедиться, что вы соблюдаете требования к рендерингу.

Далее идут автомобили, которые включают Android Auto и Android Automotive OS.

Для Android Auto и Android Automotive OS есть категории, которые уникальны для этого типа устройств.

Кроме того, в автомобилях можно публиковать только приложения определенных категорий.

Если вы отправите приложение в категорию, которая не соответствует одной из поддерживаемых, или если вы отправите приложение на открытое тестирование или в рабочую версию для категории, которая находится только в бета-версии, это приведет к отклонению.

Давайте рассмотрим это подробнее.

Здесь вы можете увидеть обзор категорий приложений, которые поддерживаются в автомобилях для каждой платформы, а также их доступность.

Например, находится ли она на стадии бета-тестирования, общедоступна или пока не поддерживается (в этом случае будет указано "Скоро").

Некоторые категории, например навигация или интересные места, общедоступны. Это значит, что любой разработчик может опубликовать рабочую версию приложения из этих категорий для автомобилей.

Другие категории, например приложения для звонков в Android Auto, находятся на этапе бета-тестирования.

Вы можете опубликовать приложение из этих категорий для внутреннего тестирования или канала закрытого тестирования, но не сможете опубликовать рабочую версию, пока не будете приняты в одну из программ раннего доступа для этой категории.

Подробную информацию об этом и многом другом вы найдете в руководствах для разработчиков Android для автомобилей.

Там вы найдете ссылки, по которым можно подать заявку на участие в программах раннего доступа.

Ещё одна распространенная причина отклонения приложений – отсутствие или неправильные характеристики скриншотов для Android Automotive OS.

Поэтому, когда вы загружаете скриншоты для Android Automotive OS, убедитесь, что вы добавили как минимум два вертикальных и два горизонтальных скриншота с указанными здесь размерами.

Для этого можно использовать эмулятор Android Automotive OS.

Она настроена так, чтобы делать скриншоты нужного размера.

И наконец, безопасность имеет первостепенное значение для приложений для автомобилей.

Если ваше приложение не соответствует нашим рекомендациям по отвлекающим факторам, оно будет отклонено.

Например, видеоприложение должно приостанавливать воспроизведение и не должно быть видно во время движения автомобиля.

И последнее, но не менее важное – Wear OS.

Приложения для Wear OS могут быть отклонены, если они не оптимизированы и не отформатированы для небольших круглых экранов.

Поэтому мы рекомендуем использовать последнюю стабильную версию Compose для Wear OS. Это позволит избежать обрезки контента по краям на устройствах разных размеров и, например, обеспечит появление полосы прокрутки, когда на экране есть прокручиваемый контент.

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

Как и в случае с Android Automotive OS, приложения для Wear OS могут быть отклонены из-за отсутствия или неточности скриншотов для Wear OS.

Вот хороший пример скриншота со страницы приложения Androidify в Google Play. Он соответствует требованиям.

Поэтому убедитесь, что вы загрузили хотя бы один скриншот, на котором показано, как ваше приложение работает на устройстве Wear OS.

Какой вывод можно сделать?

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

и несколько важных советов.

Если для доступа к приложению требуется вход, предоставьте активный демоаккаунт и действительные учетные данные в разделе "Доступ к приложениям" в Play Console.

Если наши специалисты не смогут войти в аккаунт, мы не сможем протестировать ваше приложение и оно будет автоматически отклонено.

Также не забывайте выполнять свои обещания.

Не ограничивайтесь скриншотами мобильной версии.

Если ваше приложение доступно для Wear OS и Android TV, загрузите в Play Console качественные скриншоты для этих типов устройств.

И последнее, но не менее важное: будьте описательны.

Расскажите, в чем суть и ценность приложения, а также чего стоит ожидать пользователям после установки на устройствах разных типов.

Итак, возможность охватить пользователей практически везде, где бы они ни находились, – это невероятная возможность. Модульная архитектура, внутреннее тестирование для быстрой итерации, проектирование в соответствии с рекомендациями по обеспечению качества для разных типов устройств и оптимизация страниц приложения в Google Play помогут вам подготовить приложение к более плавному запуску и проверке.

Большое спасибо за внимание.

Нам не терпится увидеть, какие потрясающие приложения, оптимизированные для любых устройств, вы опубликуете в Google Play.