Edge-To-Edge 대응시 주의점

오늘은 Edge-To-Edge 대응 후 겪었던 문제를 공유하려고 합니다. Edge-To-Edge 대응에 대한 자세한 내용은 아래 아티클을 참고해주세요. Edge-To-Edge 대응 가이드 XML Layout 대응 했던 방법 XML 기반 Layout에서 Edge-To-Edge를 적용하기 위해 ViewCompat.setOnApplyWindowInsetsListener를 사용하여 대응하고 있었습니다. 하지만 모든 Activity에서 개별적으로 대응하는 것은 어려웠기 때문에, 우선적으로 최상위 Activity에서 Insets을 소비하는 기본 로직을 구현한 후, 이를 상속받은 Activity에서 필요한 경우 override하여 소비 로직을 조정하는 방식으로 적용했습니다. 이 과정에서 findViewById(android.R.id.content)를 사용하여 Activity의 최상단 Layout에서 Window Insets을 소비하는 로직을 구현했습니다. 한 문제를 마주하기 전까지 모든 것이 순조롭게 진행되는 듯했습니다. 문제 발단 정상적으로 동작하던 레이아웃에서, 특정 SDK 실행 후 windowInset을 소비하는 로직이 초기화되는 현상이 발생했습니다. 그 결과, 위 이미지처럼 TopAppBar와 BottomAppBar가 StatusBar 또는 NavigationBar 크기만큼 패딩이 추가되는 문제가 나타났습니다. 원인 분석 SDK 내부에 구현된 코드를 살펴보면, 문제가 발생한 원인을 파악할 수 있습니다. SDK에서는 WindowInsets을 계산하기 위해 parentViewGroup(즉, android.R.id.content)에 setOnApplyWindowInsetsListener를 설정하고, insets 계산이 끝난 후 이를 하위 View에 전달합니다. 문제는 마지막에 ViewCompat.requestApplyInsets(parentViewGroup)를 호출하면서, parentViewGroup을 기준으로 다시 한 번 Insets 소비 로직이 실행된다는 점입니다. 이로 인해 기존에 구현한 Insets 소비 로직이 SDK의 로직으로 대체되면서, 결국 의도치 않은 Insets이 추가되는 문제가 발생한 것입니다. 해결 방법 이 문제를 해결하기 위해 두 가지 방법을 고려할 수 있었습니다. DataBinding을 사용하는 경우 binding.root를 활용하여 최상단 Layout의 View를 가져오는 방법 SDK의 Insets 계산 로직을 커스텀하여 직접 제어하는 방법 저는 다른 SDK나 라이브러리에서도 동일한 Insets 처리 로직이 있을 가능성을 고려하여, 첫 번째 방법을 선택해 binding.root를 사용하도록 변경했습니다. 만약 저처럼 android.R.id.content를 변경하기 어려운 경우라면, 사용 중인 라이브러리에서 Insets 소비 로직을 확인한 후 android.R.id.content를 사용할지 선택하면 될 것 같습니다. + 추가 해당 케이스를 GitHub에 업로드했습니다. 자세한 내용은 아래 링크에서 확인하실 수 있습니다 🙂 https://github.com/yunjaena/edge-to-edge-be-careful