Android 17 BETA, 공부 많이 된다

nano banana로 생성한 이미지 입니다.

 

Android 17 Beta 1이 2월 13일에 공개됐습니다.

The First Beta of Android 17

구글이 생각보다 빠르게 출시를 했는데요? 릴리즈 노트를 훑다가 한 줄이 눈에 걸렸습니다.

removes the developer opt-out for orientation and resizability restrictions on large screen devices

 

Android 16에서 이미 방향/크기 조절 제한이 도입됐고 당시에는 opt-out 방법을 함께 제공했습니다. 그걸 이번에 막겠다는 얘기입니다. 단순히 "이제 강제야"라고 선언한 게 아니라 Android 16에서 왜 opt-out을 열어뒀는지 그리고 왜 지금 닫는지를 생각해보면 이게 꽤 의미 있는 타이밍이라고 생각을 했습니다.

opt-out을 열어두는 건 무슨 의미인가?

Android 16에서 Google이 opt-out 경로를 함께 제공한 건 사실 의외라고 생각했습니다. 일반적으로 targetSdk를 올리면 그 버전의 동작 변경사항을 그냥 따라가게 하면서 이건 명시적으로 "너희가 준비될 때까지 기다려줄게"라고 한 거니까요.🤔

사실 개발자 생태계 전체를 한 번에 바꾸는 게 현실적으로 불가능하죠.. 방향 고정에 의존하는 앱이 얼마나 많은지 생각해보면(일단 나부터) 구글 입장에서도 그냥 강제했다가 앱들이 태블릿이나 폴더블에서 무너지면 플랫폼 이미지 자체가 손상되니까요.

그래서 Android 16에서 1년의 유예 기간을 준 거고 Android 17에서 그 기간이 벌써 끝납니다.

지금 닫는 이유

지금은 폴더블이 본격적으로 주류 시장에 들어서는 시점입니다. 이미 국내는 삼성의 폴드와 플립이 꽤나 메이저하게 퍼져있죠. 애플도 폴더블에 대한 움직임을 가지고 있는 만큼, 접히는 기기는 미래의 기술이 아닙니다. 이미 기기파편화가 심한 안드로이드 생태계에서 구글이 정비를 안 하면 사용자들은 폴더블에서 방향이 고정된 앱들을 계속 마주치게 될텐데요. 검은 여백이 생기거나 세로 고정인 채로 펼쳐진 화면을 채우지 못하는 앱이 되겠네요. 이게 쌓이면 결국 안드로이드의 폴더블 경험 전체에 대한 인식으로 번질 수 있습니다.

역시나 2027년 8월부터 신규 앱과 업데이트는 API 37 타겟팅이 필수입니다. 플랫폼 강제와 스토어 정책을 동시에 사용하는 방식이죠.

속성아 속성아, 왜요쌤 왜요쌤

API 37을 타겟팅하는 앱이 최소 너비 600dp 이상 화면에서 실행되면 다음 속성과 API가 무시됩니다.

Manifest 속성 / API	무시되는 값
screenOrientation	portrait, landscape 계열 전부
setRequestedOrientation()	동일
resizeableActivity	모든 값
minAspectRatio / maxAspectRatio	모든 값

 

예외는 두 가지입니다. android:appCategory="game"으로 분류된 게임 앱과 600dp 미만 폰 형태 화면은 이 제한을 받지 않습니다. 그리고 사용자는 시스템 설정에서 앱별로 동작을 개별 오버라이드할 수 있어요.

Configuration Change에 면접질문 추가요

적응형 UI 강제화와 같은 방향의 변화가 하나 더 있는데 같이 짚어두고 싶습니다.

Android 17부터 일부 Configuration Change가 발생해도 Activity를 기본적으로 재시작하지 않습니다. 대신 onConfigurationChanged()만 호출합니다. 해당하는 변경은 다음과 같습니다.

• 키보드 연결/해제 (CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN)
• 내비게이션 방식 변경 (CONFIG_NAVIGATION)
• 터치스크린 변경 (CONFIG_TOUCHSCREEN)
• 색상 모드 변경 (CONFIG_COLOR_MODE)
• 데스크 모드 UI 변경 (CONFIG_UI_MODE - UI_MODE_TYPE_DESK만 해당)

기존 동작을 생각해보면 블루투스 키보드를 연결하거나 폴더블 기기를 펼칠 때 Activity가 처음부터 재시작됐습니다. 재시작이 일어나면 스크롤 위치가 초기화되거나 입력 중이던 내용이 날아가는 일이 생깁니다. 앱이 UI를 다시 그릴 이유가 없는데도 재시작이 일어났던 겁니다.

이 변화가 중요한 이유는 방향 고정 제거와 맞물려서 훨씬 큰 의미를 갖기 때문입니다. 방향 제한이 풀리면 앱의 창 크기가 변할 기회가 훨씬 많아집니다. 기기 회전, 폴드/언폴드, 멀티 윈도우 크기 조정이 모두 Configuration Change입니다. 여기서 매번 Activity를 재시작하면 상태 손실이 너무 잦겠죠. 구글 입장에선 방향 제한을 강제로 풀면서 동시에 "하지만 Configuration Change로 인한 재시작은 줄여줄게"라는 식의 보완책을 함께 넣은 거라고 생각합니다. 동시에 Compose에 친화적이기도 하고요.

단 앱이 이 이벤트에서 리소스를 다시 로드하기 위해 재시작에 의존하고 있다면 문제가 됩니다. 이 경우 Manifest에 새로 추가된 android:recreateOnConfigChanges 속성으로 명시적으로 opt-in해야 합니다.

<activity
    android:name=".MyActivity"
    android:recreateOnConfigChanges="keyboard|keyboardHidden|navigation" />

이게 단순히 레이아웃 수정으로 끝나지 않는 이유

방향 고정을 제거한다고 하면 "레이아웃 좀 수정하면 되겠지"라고 생각하기 쉬운데 실제로 가장 많이 깨지는 부분은 카메라 프리뷰입니다.

카메라 프리뷰가 깨지는 근본 원인은 앱이 센서 방향과 기기 방향 사이의 관계를 고정으로 가정하기 때문이에요. 기기가 항상 세로라고 가정하면 센서 방향(보통 90도 회전)과 디스플레이 방향 사이의 변환을 계산할 때 논리가 단순해집니다. 그런데 가로나 임의 각도로 열리는 폴더블이 나오면 이 가정이 깨집니다.

여기서 창 크기까지 자유롭게 바뀌면 문제가 더 복잡해지는데, 멀티 윈도우나 데스크탑 윈도잉 환경에서는 앱이 화면의 일부만 차지하기 때문에 화면 크기를 기준으로 뷰파인더 크기를 계산하면 늘어집니다. 뷰파인더 크기는 반드시 Window Metrics 기준으로 계산해야 합니다.

이런 이유 때문에 구글은 Jetpack CameraX의 PreviewView 사용을 공식적으로 권장합니다. PreviewView는 센서 방향, 기기 회전, 스케일 조정을 내부적으로 처리하기 때문에 방향이 어떻게 바뀌든 프리뷰를 올바르게 표시해줍니다.

그 외 눈에 띄는 것들

적응형 UI 강제화 외에도 개인적으로 흥미로운 변경이 몇 가지 있습니다.

ART에 세대별 가비지 컬렉션이 들어왔습니다. ART의 CMC(Concurrent Mark-Compact) 수집기에 Generational GC가 도입됐습니다. 대부분의 객체가 생성 직후 빠르게 죽는다는 사실을 이용해 짧게 사는 객체는 빈번하지만 비용이 낮은 수집으로 처리하고 오래 사는 객체는 덜 자주 수집합니다. GC가 메인 스레드를 멈추는 pause time을 줄이는 데 직접적인 영향을 줍니다.

GC 최고

MessageQueue가 lock-free 구현으로 교체됩니다. 기존 MessageQueue는 내부에 락이 있어서 메인 스레드와 다른 스레드가 동시에 메시지를 넣으려 할 때 경합이 생겼습니다. SDK 37 타겟팅 앱은 lock-free 구현을 사용하게 되는데 주의할 점은 MessageQueue의 private 필드나 메서드에 리플렉션으로 접근하는 코드가 있다면 깨질 수 있어요.

그리고 static final 필드 수정이 막힙니다. SDK 37부터 static final로 선언된 필드를 리플렉션으로 수정하면 IllegalAccessException이 발생합니다. JNI의 SetStatic<Type>Field로 수정하면 즉시 크래시가 납니다. Mockito 등으로 테스트 코드에서 상수를 교체하는 패턴이 있다면 targetSdk 올리기 전에 확인이 필요합니다.

마치며

1,2년 사이에 하드웨어적으로 많은 발전이 이뤄졌다고 생각해요. 덕분에 트라이폴드 같은 기기가 상용화까지 가능하지 않았나 싶습니다. 하지만 대응은 언제나 개발자의 몫….

방향 고정을 쓰고 있던 앱은 targetSdk 37로 올리기 전에 대형 화면과 폴더블에서 어떻게 보이는지 먼저 확인해봐야 합니다. Android Studio에서 에뮬레이터를 열어서 targetSdkPreview = "CinnamonBun"으로 설정하면 지금 당장 테스트해볼 수 있습니다. Retain API 도 활용해보면 좋을까요?

이번 글은 여기서 마칩니다. 긴글 읽어 주셔서 감사합니다😊

 

 

 

참고: Android 17 Beta 1 공식 발표 · Android 17 출시 노트 · 적응형 UI 대응 가이드