2025년에 Android 16을 출시하면서 Google은 앱이 휴대전화, 폴더블, 태블릿, 데스크톱, 자동차 디스플레이 또는 XR 등 모든 화면에 원활하게 적응하는 기기 생태계에 관한 비전을 공유했습니다. 사용자는 앱이 어디에서나 작동하기를 기대합니다. 태블릿에서 멀티태스킹을 하든, 편안하게 읽을 수 있도록 기기를 펼치든, 데스크톱 창 환경에서 앱을 실행하든 사용자는 UI가 사용 가능한 디스플레이 공간을 채우고 기기 자세에 맞게 조정되기를 기대합니다.

Google은 적응형 동작을 지원하기 위해 방향 및 크기 조절 가능 여부 API에 중대한 변경사항을 도입하는 동시에 전환을 지원하기 위해 일시적인 선택 해제 옵션을 제공했습니다. API 수준 36을 타겟팅할 때 이미 많은 개발자가 이 전환에 성공적으로 적응했습니다.

이제 Android 17 베타 출시와 함께 Google은 적응형 로드맵의 다음 단계로 이동합니다. Android 17 (API 수준 37)에서는 대형 화면 기기 (sw > 600dp)의 방향 및 크기 조절 가능 여부 제한에 관한 개발자 선택 해제 옵션이 삭제 됩니다. API 수준 37을 타겟팅하는 경우 앱은 다양한 디스플레이 크기에 적응할 수 있어야 합니다.

동작 변경사항을 통해 Android 생태계는 모든 기기 폼 팩터에서 일관된 고품질 환경을 제공할 수 있습니다.

Android 17의 변경사항

Android 17을 타겟팅하는 앱은 Android 16에서 도입된 매니페스트 속성 및 런타임 API의 단계적 폐지에 따른 호환성을 보장해야 합니다. 일부 앱의 경우 전환이 클 수 있으므로 이 블로그 게시물에는 나중에 발생할 수 있는 일반적인 문제를 방지하는 데 도움이 되는 권장사항과 도구가 포함되어 있습니다.

Android 16 이후 새로운 변경사항은 도입되지 않았지만 더 이상 개발자 선택 해제는 불가능합니다. 참고로, 앱이 대형 화면에서 실행되는 경우(여기서 대형 화면은 디스플레이의 더 작은 크기가 600dp 이상임을 의미함) 다음 매니페스트 속성 및 API는 무시됩니다.

참고: Android 16에서 이전에 언급한 바와 같이 이러한 변경사항은 sw 600dp보다 작은 화면 또는 android:appCategory 플래그를 기반으로 게임으로 분류된 앱에는 적용되지 않습니다. 

또한 사용자는 제어 권한을 유지합니다. 사용자는 가로세로 비율 설정에서 앱의 요청된 동작을 사용하도록 명시적으로 선택할 수 있습니다.

앱 준비

더 이상 가로세로 비율과 방향을 세로 모드 또는 가로 모드로 제한할 수 없으므로 앱은 크기 조절이 가능한 창을 비롯해 사용자가 앱을 선택하여 사용할 수 있는 모든 가로세로 비율의 디스플레이 크기에 관한 가로 및 세로 모드 레이아웃을 지원해야 합니다.

앱 테스트

첫 번째 단계는 이러한 변경사항을 적용하여 앱을 테스트하고 앱이 다양한 디스플레이 크기에서 잘 작동하는지 확인하는 것입니다.

Android 스튜디오에서 Pixel Tablet 및 Pixel Fold 시리즈 에뮬레이터와 함께 Android 17 베타 1을 사용하고 targetSdkPreview = “CinnamonBun”을 설정합니다. 또는 앱이 아직 API 수준 36을 타겟팅하지 않는 경우 UNIVERSAL_RESIZABLE_BY_DEFAULT 플래그를 사용 설정하여 앱 호환성 프레임워크를 사용할 수 있습니다.

레이아웃이 올바르게 조정되도록 하는 추가 도구가 있습니다. Compose UI Check를 사용하여 UI를 자동으로 감사하고 UI를 더 적응형으로 만드는 방법에 관한 제안을 받을 수 있으며, DeviceConfigurationOverride를 사용하여 테스트에서 특정 디스플레이 특성을 시뮬레이션할 수 있습니다.

이전에는 방향과 가로세로 비율을 제한했던 앱의 경우 구성 변경을 처리할 때 카메라 미리보기가 기울어지거나 방향이 잘못 지정되고, 레이아웃이 늘어나고, 버튼에 액세스할 수 없거나, 사용자 상태가 손실되는 문제가 흔히 발생합니다. 

이러한 일반적인 문제를 해결하기 위한 몇 가지 전략을 살펴보겠습니다.

카메라 호환성 보장

가로 모드 폴더블 또는 멀티 윈도우, 데스크톱 창, 연결된 디스플레이와 같은 시나리오에서 가로세로 비율을 계산할 때 카메라 미리보기가 늘어나거나 회전하거나 잘리는 문제가 흔히 발생합니다.

카메라 미리보기가 늘어나거나 회전하지 않도록 합니다.

이 문제는 대형 화면 및 폴더블 기기에서 자주 발생합니다. 앱이 카메라 기능 (예: 가로세로 비율 및 센서 방향)과 기기 기능 (예: 기기 방향 및 자연 방향) 간의 고정된 관계를 가정하기 때문입니다.

카메라 미리보기가 창 크기 또는 방향에 올바르게 적응하도록 하려면 다음 네 가지 해결 방법을 고려하세요.

해결 방법 1: Jetpack CameraX (권장) 

가장 간단하고 강력한 해결 방법은 Jetpack CameraX 라이브러리를 사용하는 것입니다. PreviewView UI 요소는 모든 미리보기 복잡성을 자동으로 처리하도록 설계되었습니다.

• PreviewView는 센서 방향, 기기 회전, 확장에 맞게 올바르게 조정됩니다.
• PreviewView는 일반적으로 가운데 맞춤 및 자르기 (FILL_CENTER)를 통해 카메라 이미지의 가로세로 비율을 유지합니다.
• 필요한 경우 확장 유형을 FIT_CENTER로 설정하여 미리보기를 레터박스 처리할 수 있습니다.

자세한 내용은 CameraX 문서의 미리보기 구현을 참고하세요.

해결 방법 2: CameraViewfinder 

기존 Camera2 코드베이스를 사용하는 경우 CameraViewfinder 라이브러리 (API 수준 21과 이전 버전 호환)도 최신 해결 방법입니다. TextureView 또는 SurfaceView를 사용하고 필요한 모든 변환 (가로세로 비율, 확장, 회전)을 적용하여 카메라 피드 표시를 간소화합니다.

자세한 내용은 카메라 뷰파인더 소개 블로그 게시물 및 카메라 미리보기 개발자 가이드를 참고하세요.

해결 방법 3: 수동 Camera2 구현 

CameraX 또는 CameraViewfinder를 사용할 수 없는 경우 방향과 가로세로 비율을 수동으로 계산하고 각 구성 변경 시 계산이 업데이트되도록 해야 합니다.

• CameraCharacteristics에서 카메라 센서 방향 (예: 0, 90, 180, 270도)을 가져옵니다.
• 기기의 현재 디스플레이 회전 (예: 0, 90, 180, 270도)을 가져옵니다.
• 카메라 센서 방향 및 디스플레이 회전 값을 사용하여 SurfaceView 또는 TextureView에 필요한 변환을 결정합니다.
• 왜곡을 방지하려면 출력 Surface의 가로세로 비율이 카메라 미리보기의 가로세로 비율과 일치하는지 확인합니다.

중요: 카메라 앱은 멀티 윈도우 또는 데스크톱 창 모드 또는 연결된 디스플레이에서 화면의 일부에서 실행될 수 있습니다. 따라서 화면 크기를 사용하여 카메라 뷰파인더의 크기를 결정해서는 안 됩니다. 대신 창 측정항목을 사용하세요. 그렇지 않으면 카메라 미리보기가 늘어날 위험이 있습니다.

자세한 내용은 카메라 미리보기 개발자 가이드 및 다양한 폼 팩터의 카메라 앱 동영상을 참고하세요.

해결 방법 4: 인텐트를 사용하여 기본 카메라 작업 실행 

카메라 기능이 많이 필요하지 않은 경우 간단하고 직접적인 해결 방법은 기기의 기본 카메라 애플리케이션을 사용하여 사진이나 동영상 촬영과 같은 기본적인 카메라 작업을 실행하는 것입니다. 이 경우 카메라 라이브러리와 통합하는 대신 Intent를 사용하면 유지보수 및 적응성이 더 쉬워집니다. 

자세한 내용은 카메라 인텐트를 참고하세요.

늘어난 UI 또는 액세스할 수 없는 버튼 방지

앱이 특정 기기 방향 또는 디스플레이 가로세로 비율을 가정하는 경우 이제 다양한 방향 또는 창 크기에서 앱을 사용할 때 문제가 발생할 수 있습니다.

대형 화면에서 버튼, 텍스트 필드, 기타 요소가 늘어나지 않도록 합니다.

버튼, 텍스트 필드, 카드를 fillMaxWidth 또는 match_parent로 설정했을 수 있습니다. 휴대전화에서는 멋지게 보입니다. 하지만 가로 모드의 태블릿 또는 폴더블에서는 UI 요소가 대형 화면 전체로 늘어납니다. 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를 사용하면 다시 만들기를 선택 해제하고 대신 창 크기 변경을 통해 사용 가능한 새 공간을 반영하도록 UI를 재구성할 수 있습니다.

_UI 상태 저장_에 관한 가이드를 참고하세요.

2027년 8월까지 API 수준 37 타겟팅

이전에 API 수준 36을 타겟팅할 때 이러한 변경사항을 선택 해제한 앱은 앱이 API 수준 37을 타겟팅한 후에만 Android 17 선택 해제 삭제의 영향을 받습니다. 사전 계획을 세우고 앱에 필요한 조정을 할 수 있도록 이러한 변경사항이 적용되는 시점을 보여주는 타임라인은 다음과 같습니다.

• Android 17: 위에 설명된 변경사항은 API 수준 37을 타겟팅하는 앱 의 대형 화면 기기 (최소 화면 너비 > 600dp)의 기본 환경이 됩니다. 개발자는 선택 해제할 수 없습니다.

특정 API 수준을 타겟팅하기 위한 마감일은 앱 스토어마다 다릅니다. Google Play의 경우 새 앱과 업데이트는 API 수준 37을 타겟팅해야 하므로 2027년 8월에 배포하려면 이 동작이 필수입니다.

Android 17 준비

Android 17의 앱에 영향을 미치는 모든 변경사항은 Android 17 변경사항 페이지를 참고하세요. 앱을 테스트하려면 Android 17 베타 1을 다운로드하고 targetSdkPreview = “CinnamonBun”으로 업데이트하거나 앱 호환성 프레임워크를 사용하여 특정 변경사항을 사용 설정하세요.

Android의 미래는 적응형이며 Google은 개발자가 미래를 준비할 수 있도록 지원합니다. Android 17을 준비할 때 적응형 레이아웃 빌드 가이드와 대형 화면 품질 가이드라인을 검토하는 것이 좋습니다. 이러한 리소스는 개발자가 여러 폼 팩터와 창 크기를 자신 있게 처리할 수 있도록 설계되었습니다.

기다리지 마세요. 지금 바로 Android 17을 준비하세요.