Как подготовить приложение к изменениям в Android 17, связанным с изменением размера и ориентации

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

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

С выпуском бета-версии Android 17 мы переходим к следующему этапу адаптивной дорожной карты: в Android 17 (уровень API 37) разработчики больше не смогут отключать ограничения на ориентацию и изменение размера для устройств с большим экраном (sw > 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”. Если ваше приложение пока не поддерживает целевой уровень API 36, вы можете использовать тестирование на совместимость, включив параметр UNIVERSAL_RESIZABLE_BY_DEFAULT.

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

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

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

Проверьте совместимость камеры

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

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

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

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

Решение 1. Jetpack CameraX (рекомендуется) 

Самое простое и надежное решение – использовать библиотеку Jetpack CameraX. Элемент интерфейса PreviewView автоматически решает все сложности, связанные с предварительным просмотром:

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

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

Решение 2. CameraViewfinder 

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

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

Решение 3. Реализация Camera2 вручную 

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

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

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

Дополнительную информацию можно найти в руководстве для разработчиков по предварительному просмотру с камеры и видео Your Camera app on different form factors (Приложение "Камера" на устройствах с разными форм-факторами).

Решение 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 Beta 1 и обновите его до версии targetSdkPreview = “CinnamonBun” или используйте тестирование на совместимость, чтобы включить определенные изменения.

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

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