The Android Show(I/O 에디션) 키노트가 끝난 새벽, 저는 build.gradle 을 다시 열고 x86_64 ABI 옵션부터 켰습니다. 가을이면 정말 늦거든요.
알루미늄 OS 가을 출시까지 남은 150일, 일정의 무게
알루미늄 OS(Aluminium OS, 코드명 ALOS)는 안드로이드 17 위에 올라가는 데스크탑 OS 입니다. 크롬 OS(ChromeOS) 의 소비자 라인을 흡수해서 가을 OEM 리테일 출시를 노리는 그림으로 공개됐어요. 에이서, 에이수스, 델, HP, 레노버 등 5개 제조사가 첫 물량을 잡고 있고, 이 노트북들은 맥북에 대응하는 프리미엄 브랜드 구글북(Googlebook) 으로 묶인다고 합니다. 크롬북처럼 구글이 직접 만드는 기기가 아니라 OEM들이 만드는 카테고리 브랜드예요.
다만 구글이 반독점 소송 법정 문서(미국 v. Google)에서 광범위 출시는 2028년으로 잡혀 있다고 적시한 것으로 The Verge 가 보도했습니다. 그러니까 가을 D-150 은 OEM 제품 출시 기준이고, 전체 전환은 더 길게 본다는 얘기입니다.
엔터프라이즈와 교육용 크롬 OS 는 그대로 유지된다고 해요. 우리가 챙길 건 소비자 라인이 안드로이드 위로 올라온다는 사실 하나입니다. 그 말은 곧, 출시일부터 플레이 스토어 앱이 네이티브로 돌아간다는 의미입니다.
x86_64 ABI 빌드 복원이 첫 PR 0순위인 이유
인텔 12세대, 퀄컴, 미디어텍 콤파니오(MediaTek Kompanio) 칩이 동시에 후보로 올라가 있는 것으로 알려져 있어요. ARM 한 줄로 깔린 빌드는 이번에 통하지 않습니다. arm64-v8a 와 x86_64 듀얼 ABI 가 사실상 의무라고 보시면 됩니다.
// build.gradle.kts (app)
android {
defaultConfig {
ndk {
abiFilters += listOf("arm64-v8a", "x86_64")
}
}
}
오래된 프로젝트일수록 APK 크기 줄이려고 x86 계열을 잘라낸 흔적이 남아 있는 경우가 많습니다. 저도 옛 프로젝트 두 개에서 abiFilters 가 arm64-v8a 한 줄로만 깔려 있었어요. 네이티브 라이브러리(JNI) 를 쓰는 모듈이 있다면 x86_64 바이너리가 같이 빌드되는지 한 번 더 점검해야 합니다.
크기 부담이 걱정되면 Play App Bundle 의 ABI splits 로 받게 두면 됩니다. 사용자는 자기 칩 아키텍처에 맞는 분할만 내려받게 되니까 단말 부담은 크지 않아요.
Compose WindowSizeClass 로 어댑티브 레이아웃 첫 커밋
크롬 OS 사용자의 90% 가 키보드와 마우스로 앱과 상호작용한다는 수치가 ChromeOS.dev 가 일찍부터 공개한 자료에 나와 있습니다. 그 흐름이 알루미늄 OS 로 그대로 넘어옵니다. 터치 우선으로만 짠 앱은 데스크탑 창에 펼쳐졌을 때 멍하니 비는 구간이 생길 수 있어요.
첫 PR 로 가장 안전하게 박을 대목은 젯팩 컴포즈(Jetpack Compose) 의 WindowSizeClass 분기입니다.
@Composable
fun AppRoot(windowSizeClass: WindowSizeClass) {
when (windowSizeClass.widthSizeClass) {
WindowWidthSizeClass.Compact -> ListOnlyScreen()
WindowWidthSizeClass.Medium -> ListDetailScreen(twoPane = false)
WindowWidthSizeClass.Expanded -> ListDetailScreen(twoPane = true)
}
}
600dp, 840dp 분기점을 기준으로 List-Detail 같은 어댑티브 레이아웃을 짜두면, 같은 코드로 폰·폴더블·데스크탑 창까지 한 번에 받아냅니다. androidx.compose.material3.adaptive 라이브러리의 NavigableListDetailPaneScaffold 를 같이 보시면 더 깔끔하게 묶을 수 있어요.
개인적으로는 새 화면부터 어댑티브로 짜는 것보다, 이미 자주 쓰이는 화면 하나만 골라 List-Detail 로 리팩토링하는 PR 이 효과가 훨씬 컸습니다. 한 번 패턴을 잡아두면 나머지 화면이 빠르게 따라오더라고요.
키보드 단축키·우클릭·창 리사이즈는 D-30 체크리스트
큰 화면 분기 다음으로 묵직하게 남는 건 입력 모델입니다. 마우스 우클릭, 키보드 단축키, 창 리사이즈 시 상태 보존. 이 셋이 동시에 안 잡혀 있으면 데스크탑 창에서 앱이 어색하게 멈춰 보이는 일이 생깁니다.
- [ ] onKeyShortcut 또는 dispatchKeyShortcutEvent 로 Ctrl+N, Ctrl+F 같은 표준 단축키를 액티비티 레벨에 추가합니다.
- [ ] 길게 누름 대신 마우스 우클릭(onContextClick)을 별도 진입점으로 받습니다.
- [ ] android:resizeableActivity="true" 와 configChanges 조합을 다시 점검하고, onConfigurationChanged 와 onSaveInstanceState 로직이 창 리사이즈에서 상태를 잃지 않는지 확인합니다.
저는 D-30 시점에 실기기 두 대(폴더블 한 대, 크롬북 한 대) 에서 테스트를 돌릴 계획입니다. 데스크탑 모드 에뮬레이터로 1차 잡고, 실제 단말에서 리사이즈 핸들을 잡고 좌우로 흔들어보는 게 가장 빠른 검증이었어요.
제미나이 인텔리전스 후킹 포인트는 공개 API 안에서만
구글북에는 OS 레벨로 제미나이 인텔리전스(Gemini Intelligence) 가 들어간다고 예고됐습니다. 매직 포인터 같은 기능이 발표 영상에 잠깐 비쳤더라고요. 앱 입장에서 챙길 자리는 텍스트 선택, 드래그 페이로드, 공유 인텐트 같은 표준 진입점이 어시스턴트 호출에 잘 노출되는지입니다.
다만 발표 직후라 어시스턴트 쪽 신규 API 의 정확한 시그니처는 공식 문서로 다시 확인해야 합니다. 지금 시점에서 안전한 준비는 이미 공개된 App Actions BII, AppSearch API, shortcuts.xml 정도예요. 추측 시그니처로 코드 박아두면 발표 후 다 갈아엎어야 하니까요.
AOSP 와 Jetpack 외부 PR 창구도 D-90 부터 한 번씩 들여다볼 가치가 있습니다. 윈도우 매니저(WindowManager), Compose-adaptive 쪽에 외부 기여 자리가 열려 있을 수 있어요. AOSP 는 일반 깃허브 PR 과 절차가 달라서 CLA 서명과 사전 연락 같은 고유한 단계가 있다고 이해하면 됩니다. 미리 계정만 트여 있어도 출시 직후 패치 한 줄 보내는 데 큰 차이가 납니다.
가을이 오기 전에 손에 잡히는 지점
알루미늄 OS 가 정말 가을에 리테일로 풀리는지, 아니면 베타로 한 분기를 더 끄는지는 아직 변동의 여지가 있는 대목입니다. 다만 듀얼 ABI 복원과 WindowSizeClass 분기, 이 두 가지는 알루미늄 OS 와 무관하게 지금 폴더블·태블릿 시장에서도 이미 본전을 뽑는 작업이지요.
발표 직후의 잠깐을 흘려보내면, 가을에는 출시 노이즈에 묻혀 PR 우선순위에서 밀려납니다. 저는 이번 주말 안에 0순위 두 개를 메인 브랜치에 머지하고, 단축키와 창 리사이즈는 다음 스프린트에 잡아둘 생각입니다.
'Android 개발 > Gradle・빌드' 카테고리의 다른 글
| Gradle 빌드가 갑자기 느려졌을 때 가장 먼저 보는 곳 (0) | 2026.05.05 |
|---|