Android 16 Beta

targetSdk 35 Edge-To-Edge(전체 화면 모드) 대응 안녕하세요. 원티드랩 후보자 경험 2팀의 나윤재입니다. 원티드랩에서는 매 반기마다 2주간 모든 신규 개발과 정기 회의를 멈추고, 기술 부채를 해소하고 품질을 개선하는 데 집중하는 “엔지니어링 위크”를 운영하고 있습니다. 이 기간 동안에는 버그 수정, 기술 기반 개선, 문서화 작업 등 서비스 향상을 위한 다양한 주제로 문제를 해결하고 있습니다. 이번 엔지니어링 위크에서는 Android 버전 업데이트 주기에 맞춰 “targetSdk 35(Android 15)”에 미리 대응하는 작업을 진행했습니다. Android 15에는 여러 변경사항이 있었지만, 이번 글에서는 그중에서도 “Edge-to-Edge(전체 화면 모드)”에 대해 알아보고, 이를 실무에서 어떻게 효과적으로 대응할 수 있는지 공유드리고자 합니다. 💡 Edge To Edge 란? “Edge-to-Edge(전체 화면 모드)”는 Android에서 화면 전체를 활용해 콘텐츠를 표시하는 방식입니다. 기존에는 시스템 UI(상단의 상태 표시줄, 하단의 내비게이션 바 등)가 앱 콘텐츠와 분리되어 있었으며, 필요에 따라 전체 화면 모드를 수동으로 구현해야 했습니다. 그러나 targetSdk 35(Android 15) 이상을 타겟팅할 경우, 기본으로 콘텐츠가 시스템 UI 영역까지 확장되며, 개발자가 필요한 영역을 지정하여 시스템 UI와의 영역 겹치는 부분을 관리해야 합니다. 이를 통해 더 유연하고 사용자 몰입감을 높이는 화면 구성을 가능하게 합니다. Android 15 미만에서 edge to edge를 활성화하기 위해서는 onCreate()에 enableEdgeToEdge()를 선언합니다. ime 의 크기를 인셋으로 받기 위해서 AndroidManifest 에서android:windowSoftInputMode="adjustResize" 속성을 추가해줍니다. enableEdgeToEdge 메서드 내부에서는 WindowCompat.setDecorFitsSystemWindows(window, false) 가 설정되어있으며, 이를 통해서 사용자가 직접 inset을 직접 컨트롤 할 수 있게 해줍니다. 💡 WindowInset 전체 화면 모드를 활용하기에 앞서 windowInset에 대한 개념을 짚고 가겠습니다. 앱이 Edge-to-Edge 모드를 사용할 때, 중요한 콘텐츠나 상호작용이 시스템 UI에 의해 가려지지 않도록 해야 합니다. 예를 들어, 버튼이 내비게이션 바 뒤에 배치되면 사용자가 버튼을 클릭할 수 없게 될 수 있습니다. 시스템 UI의 크기와 위치에 대한 정보는 “인셋(insets)”을 통해 지정됩니다. 시스템 UI의 각 부분에는 해당하는 인셋 유형이 있으며, 이는 시스템 UI의 크기와 위치를 나타냅니다. 예를 들어, 상태 표시줄 인셋은 상태 표시줄의 크기와 위치를 제공하고, 내비게이션 바 인셋은 내비게이션 바의 크기와 위치를 제공합니다. 각 인셋 유형은 상단, 좌측, 우측, 하단의 네 가지 픽셀 크기로 구성되며, 이는 시스템 UI가 앱 창의 해당 면에서 얼마나 확장되는지를 나타냅니다. 따라서 앱 UI가 해당 시스템 UI와 겹치지 않도록 하려면, 앱 UI는 해당 크기만큼 인셋을 적용해야 합니다. 해당 인셋 유형은 “WindowInsets” 를 통해 알 수 있습니다. 💡 Platform Insets API / “Safe” Insets API Modifier.windowInsetPadding을 사용하면 창 인셋에 맞춰 패딩을 자동으로 적용할 수 있습니다. 예를 들어, Modifier.windowInsetPadding(WindowInsets.statusBar)를 사용하면 상태바 크기만큼 패딩이 추가됩니다. 이때 "safe"라는 접두어가 붙은 API들이 사용되는 경우가 있는데, 이는 여러 인셋 타입을 결합 되어있습니다. 예를 들어, safeDrawing은 아래와 같이 선언되어 있습니다 val safeDrawing = systemBars.union(ime).union(displayCutout) 이 코드에서 systemBars, ime, displayCutout 인셋을 합친 값으로, 시스템 UI에 의해 가려진 부분이 콘텐츠에 영향을 주지 않도록 하여 안전하게 그릴 수 있게 도와줍니다. safeGesture는 다음과 같이 선언되어있습니다. val safeGestures: WindowInsets = tappableElement.union(mandatorySystemGestures).union(systemGestures).union(waterfall) 이 API는 제스처로 인한 사용자 인터페이스의 겹침을 방지하는 데 사용됩니다. 예를 들어, 제스처 네비게이션이 활성화된 상태에서 뒤로 가기 제스처가 발생하면, 리스트와 제스처 영역이 겹칠 수 있는데, safeGestures는 이를 방지하여 제스처가 콘텐츠와 충돌하지 않도록 도와줍니다. 마지막으로 safeContent는 safeDrawing과 safeGesture가 합쳐져있습니다. 💡 편리하게 활용할 수 있는 API 앞서 설명드린 inset padding을 쉽게 사용할 수 있는 API가 있습니다. Modifier.safeDrawingPadding() Modifier.statusBarsPadding() Modifier.navigationBarsPadding() 등이 있으며, 내부적으로 windowInsetPadding으로 구현되어 있는것을 알 수 있습니다. 💡 인셋 소비 여기서 한 가지 의문이 생길 수 있습니다. Modifier.windowInsetPadding을 사용해 인셋 패딩을 적용했는데, 하위 composable에서 동일한 인셋 패딩 설정이 되어 있다면 중복 적용될 수 있지 않을까 하는 생각이 들 수 있습니다. 하지만 windowInsetPadding 내부를 살펴보면, 이러한 걱정은 할 필요가 없다는 사실을 알 수 있습니다. windowInsetPadding은 InsetsPaddingModifier 인스턴스를 가지고 있으며, 이 클래스는 LayoutModifier, ModifierLocalConsumer, ModifierLocalProvider를 상속받고 있습니다. LayoutModifier는 인셋을 기반으로 위치를 조정하는 데 사용됩니다. ModifierLocalConsumer는 이 수정자보다 왼쪽에 있거나 레이아웃 트리에서 위쪽에 있는 다른 수정자들에 의해 제공된 ModifierLocals를 소비하는 역할을 하며, 여기서는 상위에서 받은 인셋을 바탕으로 소비된 인셋과 소비되지 않은 인셋을 계산합니다. ModifierLocalProvider는 소비된 인셋을 하위 composable에게 전달하는 역할을 합니다. 따라서, 중복 적용에 대한 걱정 없이, 상위에서 처리된 인셋은 하위 composable로 자연스럽게 전달된다는 사실을 알 수 있습니다. 하지만 만약 WindowInsets.asPaddingValues()와 같이 직접 windowInset의 값을 사용했을 경우, 하위 composable에 중복적으로 windowInset 패딩이 적용되는 것을 방지하려면 Modifier.consumeWindowInsets(paddingValues) 수정자를 사용해야 합니다. 이 수정자는 해당 인셋을 소비하여 하위 composable에게 중복 적용되지 않도록 처리해줍니다. 이를 통해 상위에서 직접 설정한 인셋이 하위 composable에서 다시 적용되지 않도록 할 수 있습니다. 💡 Android View(XML)에서 해결 방법 Compose와 달리, 일반 Android View에서는 인셋을 처리하는 방법이 다릅니다. ViewCompat.setOnApplyWindowInsetsListener를 사용하여 인셋을 계산하고, 그 후에 view에 padding을 설정한 뒤, 인셋을 전체 소비할지 아니면 하위 view에게 남은 인셋을 전달할지를 결정할 수 있습니다. 예시 코드는 다음과 같습니다 위 코드에서 systemBars 크기만큼 container view에 padding을 추가한 후, 해당 인셋을 소비하고 있습니다. 이 경우, 하위 view에게는 인셋을 전달하지 않습니다. 만약 하위 view에게 systemBars를 제외한 나머지 인셋을 전달하려면, WindowInsetsCompat.inset(@NonNull Insets insets) 메서드를 사용하여 하위 view에 남은 인셋을 전달할 수 있습니다. 💡 Material 컴포넌트에서 WindowInset 대응 방법 Material3와 Material 1.6.0 이상에서는 WindowInsets를 활용한 대응이 가능합니다. 예를 들어, 자주 사용하는 Scaffold의 경우, 아래와 같이 contentWindowInsets 파라미터를 기본적으로 제공합니다. contentWindowInsets: WindowInsets = ScaffoldDefaults.contentWindowInset 만약 topBar나 bottomBar가 설정되지 않았다면, 내부적으로 systemBar(statusBar + navigationBar + captionBar) 의 패딩이 기본적으로 적용됩니다. 그러나 systemBar만큼의 패딩 없이 화면을 꽉 채우고 싶다면, contentWindowInsets에 WindowInsets 값을 0으로 설정하여 전체 화면을 구성할 수 있습니다. Scaffold에 TopBar나 BottomBar를 추가하려면, Material에서 제공하는 TopAppBar와 BottomAppBar를 사용하는 것이 좋습니다. 이 컴포넌트들도 각각 windowInsets 파라미터를 제공하여 시스템 UI와의 겹치는 부분을 조정합니다. TopAppBar: systemBar의 Horizontal(수평) 과 Top(상단 상태 표시줄) 패딩이 적용됩니다. BottomAppBar: systemBar의 Horizontal(수평) 과 Bottom(하단 내비게이션 영역) 패딩이 적용되어, 시스템 UI와 겹치지 않고 안전하게 렌더링됩니다. Scaffold에서 파라미터 이름이 windowInsets가 아닌 contentWindowInsets인 이유는, topBar와 bottomBar 같은 영역이 이미 인셋을 소비한 이후 남은 콘텐츠 영역에만 추가로 인셋을 적용하기 위함입니다. 이를 통해 콘텐츠 영역에서 중복된 인셋이 발생하지 않도록 방지합니다. 결론적으로, Material3와 Material 1.6.0 이상에서는 WindowInsets를 활용하여 더 유연하고 안전한 UI 구성이 가능하며, WindowInsets 파라미터를 적절히 활용하면 시스템 UI와 겹치지 않으면서도 최적화된 레이아웃을 구현할 수 있습니다. 💡 실제 프로덕션에서 대응 방법 원티드 서비스에서 targetSdk를 35로 설정하고 Android 15 디바이스에서 실행했을 때, 대부분의 UI가 깨져서 표시되는 문제가 발생했습니다. 현재 원티드 프로젝트는 주로 Compose로 구현되어 있으며, 일부는 XML로, 일부는 두 가지 방식이 혼합된 형태로 구성되어 있습니다. 1. Compose에서의 대응 앞서 말씀드린 것처럼, Scaffold, TopAppBar 등 Material3 컴포넌트는 기본적으로 windowInset에 대응하지만, 저희 서비스는 자체 디자인 시스템을 사용하여 별도로 구현된 topBar와 bottomBar가 있어 windowInset에 대한 대응이 되어 있지 않았습니다. 따라서, 디자인 시스템의 topBar에 windowInset 파라미터를 추가하고, WantedTopAppBarDefaults.windowInset을 기본값으로 설정했습니다. 이를 통해 statusBar의 높이를 신경 쓰지 않고 자동으로 해당 크기만큼 패딩이 적용되었습니다. 또한, 모달이나 bottomSheet에 topBar를 사용할 때는 statusBar 크기만큼의 패딩이 필요 없으므로, WindowInsets(0) 값을 전달하여 꽉 차게 표시되도록 처리했습니다. 2. XML 기반 화면에서의 대응 XML로 구현된 화면은 2주 내에 전체를 수정하기 어려웠습니다. 그러나 다행히 BindingActivity를 상속한 Activity가 있어, 해당 Activity에서 windowInset을 추가하는 코드를 적용할 수 있었습니다. 최상단 view를 가져와 systemBars와 ime 인셋만큼 패딩을 추가하고, 하위 view에는 인셋을 전달하지 않았습니다. 이를 통해 대부분의 view에 대해 대응할 수 있었으며, 전체 화면을 요구하는 경우에는 setupWindowInsets 메서드를 오버라이드하여 조정할 수 있었습니다. 3. 제스처 네비게이션 모드에서의 대응 제스처 네비게이션을 사용할 경우, 리스트를 보여줄 때 아래에 흰색 공백이 보이는 문제가 발생했습니다. Scaffold 안에 LazyColumn이 있는 경우, Scaffold의 topBar에 windowInset을 0으로 설정하거나 topBar와 bottomBar가 없는 경우에는 contentWindowInsets의 windowInset을 0으로 설정하여 전체 화면을 만들었습니다. 이후, LazyColumn에서 contentPadding 또는 Modifier.windowInsetsBottomHeight() 수정자를 활용하여 공백 없는 자연스러운 화면을 구현할 수 있었습니다. 지금까지 Edge-to-Edge의 개념과 대응 방법에 대해 간략하게 정리해보았습니다. 이번 작업을 통해 Android 업데이트가 점점 더 빠르게 변화하고, 이에 대한 대응이 점점 더 복잡해지고 있다는 점을 실감했습니다. Edge-to-Edge 대응에 대해 이해하기 위해 Playground를 만들어 보았습니다. 실행해보고 직접 만져보시면 더 쉽게 이해할 수 있을 것 같습니다. yunjaena/android-15-window-insets 💡 현재 원티드랩 직군확장팀에서 Android 포지션을 모집 중입니다. 많은 관심 부탁드립니다. https://www.wanted.co.kr/wd/245840

💡 Android 16을 타겟팅 하는 앱

하단 네비게이션