Экосистема Android, насчитывающая 3 с лишним миллиарда устройств с ОС Android по всему миру, сейчас динамична как никогда. Мобильные приложения Android работают на самых разных устройствах — от телефонов и раскладушек до планшетов, Chromebook, автомобилей и XR. Пользователи получают экосистему устройств и ожидают, что их приложения будут работать на всех устройствах. Чтобы процветать в этой среде, ваши приложения должны легко адаптироваться к различным размерам экрана и форм-факторам.
Многие приложения для Android используют подходы к пользовательскому интерфейсу, которые работают в одной ориентации и/или ограничивают возможность изменения размеров. Однако пользователи хотят, чтобы приложения в полной мере использовали возможности больших экранов, поэтому производители устройств Android добавили хорошо принятые функции, которые отменяют эти ограничения.
Учитывая это, Android 16 лишает приложения возможности ограничивать ориентацию и изменение размеров на уровне платформы и переходит к последовательной модели адаптивных приложений, которые легко подстраиваются под разные размеры и ориентацию экрана. Это изменение уменьшит фрагментацию, обеспечив поведение, которое лучше соответствует ожиданиям пользователей, и повысит доступность за счет уважения предпочитаемой ориентации пользователя. Google создает инструменты, библиотеки и API-интерфейсы платформы, которые помогут вам в этом, чтобы обеспечить неизменно превосходный пользовательский опыт во всей экосистеме Android.
Что меняется?
Начиная с Android 16 постепенно отменяются атрибуты манифеста и API, используемые для ограничения ориентации и изменения размера приложения, что позволит улучшить пользовательский опыт для многих приложений на разных устройствах.
Эти изменения первоначально будут применяться, если приложение запущено на большом экране, где «большой экран» означает, что наименьший размер дисплея больше или равен 600 dp. Сюда относятся:
- Внутренние дисплеи складных устройств с большим экраном
- Планшеты, в том числе с окнами рабочего стола
- Дектопные среды, включая Chromebooks
Следующие атрибуты манифеста и API будут игнорироваться в приложениях для Android 16 (SDK 36) на больших экранах:
- screenOrientation
- setRequestedOrientation()
- resizeableActivity
- minAspectRatio
- maxAspectRatio
Есть некоторые исключения для управления ориентацией, соотношением сторон и изменением размера:
- Как уже упоминалось, эти изменения не будут применяться для экранов, размер которых меньше sw600dp (например, для большинства телефонов, раскладушек, внешних дисплеев на раскладушках с большим экраном)
- Игры будут исключены из этих изменений на основании флага android:appCategory.
Кроме того, у пользователей есть возможность контролировать ситуацию. Они могут явно согласиться на использование поведения приложения по умолчанию в настройках соотношения сторон.
Подготовьтесь к этим изменениям, сделав свое приложение адаптивным
Приложения должны будут поддерживать альбомную и книжную ориентацию окон во всем диапазоне соотношений сторон, в которых пользователи могут использовать приложения, поскольку больше не будет возможности ограничивать соотношение сторон и ориентацию только портретной или только альбомной.
Чтобы проверить, повлияют ли на ваше приложение эти изменения, используйте предварительную версию Android 16 Beta 1 для разработчиков с эмуляторами серий Pixel Tablet и Pixel Fold в Android Studio и либо установите targetSdkPreview = «Baklava», либо используйте фреймворк совместимости приложений, включив флаг UNIVERSAL_RESIZABLE_BY_DEFAULT.
Для существующих приложений, ограничивающих ориентацию и соотношение сторон, эти изменения могут привести к таким проблемам, как перекрытие элементов. Чтобы решить эти проблемы и оправдать ожидания пользователей, приложения должны быть адаптивными и обеспечивать оптимальные впечатления независимо от того, на каком телефоне, раскладном устройстве, планшете, Chromebook, XR или в автомобиле они запускаются.
Решение распространенных проблем
- Избегайте растягивания компонентов пользовательского интерфейса: Если макеты разрабатывались и создавались с учетом экранов телефонов, то функциональность приложения может быть нарушена при других соотношениях сторон. Например, если макет создавался с учетом портретного соотношения сторон, то элементы пользовательского интерфейса, заполняющие максимальную ширину окна, будут выглядеть растянутыми в окнах, ориентированных на ландшафт. Если макеты не рассчитаны на прокрутку, пользователи не смогут нажимать на кнопки или другие элементы пользовательского интерфейса, находящиеся за пределами экрана, что приведет к путанице или сбоям в работе. Добавьте максимальную ширину для компонентов, чтобы избежать растягивания, и добавьте прокрутку, чтобы обеспечить доступность всего содержимого.
- Обеспечьте совместимость с камерой в обеих ориентациях: Предварительный просмотр в видоискателе камеры может предполагать определенное соотношение сторон и ориентацию относительно сенсора камеры, что приводит к растягиванию или переворачиванию предварительного просмотра, когда эти предположения нарушаются. Убедитесь, что видоискатели поворачиваются правильно и учитывают, что соотношение сторон пользовательского интерфейса отличается от соотношения сторон сенсора.
- Сохраняйте состояния при изменении размера окна: Устранение ограничений на ориентацию и соотношение сторон также означает, что размеры окон приложений будут чаще меняться в зависимости от того, как пользователь предпочитает использовать приложение, например, при повороте, сворачивании или изменении размера приложения в многооконном или свободно-форматном режимах работы с окнами. Изменение ориентации и размера по умолчанию приводит к восстановлению Активити. Для обеспечения хорошего пользовательского опыта очень важно, чтобы состояние приложения сохранялось при таких изменениях конфигурации, чтобы пользователи не потеряли свое место в приложении при смене позы или изменении оконных режимов.
Для учета различных размеров окон и соотношения сторон используйте классы размеров окон, чтобы управлять поведением макета таким образом, чтобы не требовалась настройка под конкретное устройство. Приложения также должны создаваться с учетом того, что размеры окон будут часто меняться. Нет необходимости создавать дублирующие макеты, ориентированные на конкретную ориентацию — вместо этого убедитесь, что существующие пользовательские интерфейсы могут хорошо перестраиваться независимо от размера окна. Если у вас есть макеты, ориентированные на ландшафтную или портретную ориентацию, они все равно будут использоваться.
Оптимизация под размеры окон путем создания адаптивных макетов
Если вы уже создаете адаптивные макеты и поддерживаете все ориентации, вы настроены на успех, поскольку ваше приложение будет подготовлено к каждому из типов устройств и оконных режимов, в которых пользователи захотят использовать ваше приложение, и эти изменения будут иметь минимальное влияние.
У Google также есть ряд ресурсов для тестирования, которые помогут вам гарантировать надежность. Вы можете автоматизировать тестирование с помощью таких инструментов, как фреймворк для тестирования Espresso и API для тестирования Jetpack Compose.
FlipaClip — отличный пример того, почему важно создавать приложения для разных форм-факторов: за четыре месяца после оптимизации приложения под адаптивность число пользователей планшетов выросло на 54%.
График
Эти изменения существенны для приложений, которые традиционно поддерживали только портретную ориентацию. Возможно, потребуется внести коррективы в пользовательский интерфейс, например, в случае выезжающих за пределы экрана кнопок, перекрывающегося контента или экранов с видоискателями камер.
Чтобы помочь вам спланировать и внести необходимые коррективы, вот планируемый график, в котором указаны сроки вступления в силу этих изменений:
- Android 16 (2025): Описанные выше изменения станут базовыми для устройств с большим экраном (наименьшая ширина экрана > 600dp) для приложений, использующих API уровня 36, при этом разработчики смогут отказаться от них.
- Релиз Android в 2026 году: Изменения, описанные выше, станут базовыми для устройств с большим экраном (наименьшая ширина экрана >600dp) для приложений, которые будут соответствовать уровню API 37. У разработчиков не будет возможности отказаться от этого.
Сроки перехода на определенный уровень API зависят от магазина приложений. Для Google Play планируется, что переход на API 36 потребуется в августе 2026 года, а на API 37 — в августе 2027 года.
Подготовка к Android 16
Обратитесь к странице изменений Android 16, чтобы узнать обо всех изменениях, влияющих на приложения в Android 16, а также о дополнительных ресурсах для обновления ваших приложений, если они затронут вас. Чтобы протестировать свое приложение, загрузите предварительную версию Android 16 Beta 1 для разработчиков и обновите ее до targetSdkPreview = «Baklava» или используйте фреймворк совместимости приложений, чтобы включить определенные изменения.
Следите за обновлениями и ресурсами по мере приближения выхода Android 16!