С выходом Android 16 в 2025 году мы поделились своим видением экосистемы устройств, в которой приложения плавно адаптируются к любому экрану — будь то телефон, складное устройство, планшет, настольный компьютер, автомобильный дисплей или XR. Пользователи ожидают, что их приложения будут работать везде. Будь то многозадачность на планшете, раскладывание устройства для комфортного чтения или запуск приложений в оконной среде настольного компьютера, пользователи ожидают, что пользовательский интерфейс будет заполнять доступное пространство экрана и адаптироваться к положению устройства.

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

С выходом бета-версии Android 17 мы переходим к следующему этапу нашей стратегии адаптивного дизайна: Android 17 (уровень API 37) снимает ограничения на ориентацию и изменение размера экрана для устройств с большими экранами (> 600 dp), которые ранее были недоступны разработчикам . При использовании уровня API 37 ваше приложение должно уметь адаптироваться к различным размерам экрана.

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

Что изменилось в Android 17?

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

С момента выхода Android 16 никаких новых изменений не было, но возможность отказа от участия для разработчиков больше недоступна. Напоминаем: при работе вашего приложения на большом экране (где большой экран означает, что меньший размер дисплея больше или равен 600 dp) следующие атрибуты манифеста и API игнорируются:

Примечание: Как уже упоминалось в отношении Android 16, эти изменения не применяются к экранам с разрешением менее 600 dp или к приложениям, отнесенным к категории игр на основе флага android:appCategory .

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

Подготовьте ваше приложение

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

Протестируйте своё приложение

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

Используйте Android 17 Beta 1 с эмуляторами серий Pixel Tablet и Pixel Fold в Android Studio и установите targetSdkPreview = “CinnamonBun” . В качестве альтернативы вы можете использовать фреймворк совместимости приложений , включив флаг UNIVERSAL_RESIZABLE_BY_DEFAULT если ваше приложение еще не ориентировано на API уровня 36.

У нас есть дополнительные инструменты, которые помогут обеспечить корректную адаптацию ваших макетов. Вы можете автоматически проверять свой пользовательский интерфейс и получать предложения по его повышению адаптивности с помощью Compose UI Check , а также имитировать определенные характеристики отображения в тестах с помощью DeviceConfigurationOverride .

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

Давайте рассмотрим некоторые стратегии решения этих распространенных проблем.

Убедитесь в совместимости камеры.

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

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

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

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

Решение 1: Jetpack CameraX (предпочтительный вариант)

Самое простое и надежное решение — использовать библиотеку Jetpack CameraX. Ее элемент пользовательского интерфейса PreviewView разработан для автоматической обработки всех сложностей предварительного просмотра:

• PreviewView корректно учитывает ориентацию датчика, поворот устройства и масштабирование.
• PreviewView сохраняет соотношение сторон изображения с камеры, как правило, путем центрирования и обрезки ( FILL_CENTER ).
• При необходимости можно установить тип масштабирования FIT_CENTER , чтобы отобразить предварительный просмотр в виде черных полос по бокам.

Для получения более подробной информации см. раздел «Реализация предварительного просмотра» в документации CameraX.

Решение 2: Видоискатель камеры

Если вы используете существующий код Camera2, библиотека CameraViewfinder (обратно совместимая с API уровня 21) — это еще одно современное решение. Она упрощает отображение видеопотока с камеры, используя TextureView или SurfaceView и применяя все необходимые преобразования (соотношение сторон, масштаб и вращение).

Для получения более подробной информации см. статью в блоге «Представляем Camera Viewfinder» и руководство разработчика по предварительному просмотру Camera .

Решение 3: Ручная реализация Camera2

Если вы не можете использовать CameraX или CameraViewfinder , вам необходимо вручную рассчитать ориентацию и соотношение сторон и убедиться, что расчеты обновляются при каждом изменении конфигурации:

• Определите ориентацию сенсора камеры (например, 0, 90, 180, 270 градусов) из CameraCharacteristics
• Получите текущий угол поворота дисплея устройства (например, 0, 90, 180, 270 градусов).
• Используйте значения ориентации датчика камеры и поворота дисплея, чтобы определить необходимые преобразования для вашего SurfaceView или TextureView
• Убедитесь, что соотношение сторон выходной Surface соответствует соотношению сторон предварительного просмотра с камеры, чтобы предотвратить искажения.

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

Для получения дополнительной информации см. руководство разработчика по предварительной версии приложения «Камера» и видеоролик «Ваше приложение «Камера» на различных форм-факторах» .

Решение 4: Выполнение основных действий с камерой с помощью Intent.

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

Для получения дополнительной информации см. раздел «Намерения камеры» .

Избегайте растянутого интерфейса или недоступных кнопок.

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

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

Возможно, вы установили для кнопок, текстовых полей и карточек параметры fillMaxWidth или match_parent . На телефоне это выглядит отлично. Однако на планшете или складном устройстве в альбомной ориентации элементы пользовательского интерфейса растягиваются на весь большой экран. В Jetpack Compose вы можете использовать модификатор widthIn, чтобы установить максимальную ширину для компонентов и избежать растягивания контента:

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

Если пользователь открывает ваше приложение в альбомной ориентации на складном устройстве или планшете, кнопки действий, такие как «Сохранить» или «Войти», расположенные внизу экрана, могут отображаться за пределами видимой области. Если контейнер не прокручивается, пользователь может быть заблокирован от дальнейшего использования. В Jetpack Compose вы можете добавить модификатор verticalScroll к своему компоненту:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

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

Ознакомьтесь с нашим руководством по созданию адаптивных макетов .

Сохранение состояния при изменении конфигурации.

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

По умолчанию эти изменения конфигурации уничтожают и воссоздают вашу активность. Если ваше приложение не управляет этим событием жизненного цикла должным образом, пользователи столкнутся с неудобствами: положение прокрутки сбрасывается вверх, наполовину заполненные формы очищаются, а история навигации теряется. Для обеспечения плавной адаптивной работы крайне важно, чтобы ваше приложение сохраняло состояние при этих изменениях конфигурации. С помощью Jetpack Compose вы можете отказаться от воссоздания и вместо этого разрешить изменениям размера окна перестраивать пользовательский интерфейс в соответствии с новым доступным пространством.

См. наше руководство по сохранению состояния пользовательского интерфейса .

Планируемая версия API уровня 37 к августу 2027 года.

Если ваше приложение ранее отказалось от этих изменений при переходе на API уровня 36, то после отмены возможности отказа от этих изменений в Android 17, они затронут ваше приложение только после перехода на API уровня 37. Чтобы помочь вам спланировать свои действия и внести необходимые корректировки в приложение, вот график вступления этих изменений в силу:

• Android 17: Описанные выше изменения станут базовым функционалом для устройств с большими экранами (минимальная ширина экрана > 600 dp) для приложений, ориентированных на API уровня 37. Разработчики не смогут отказаться от этих изменений.

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

Подготовка к Android 17

Для получения информации обо всех изменениях, затрагивающих приложения в Android 17, обратитесь к странице изменений Android 17. Чтобы протестировать свое приложение, загрузите Android 17 Beta 1 и обновите его, установив targetSdkPreview = “CinnamonBun” , или используйте фреймворк совместимости приложений , чтобы включить определенные изменения.

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

Не ждите. Начните подготовку к Android 17 уже сегодня!