← Docs hub

원형 디스플레이 Android 포팅과 잘리지 않는 UI

원형 UI는 Android에서 구현 가능하다. 패널 해상도에 맞춘 사각 좌표 공간 안에서 원형 가시 영역을 기준으로 설계한다. 원 밖의 내용은 보이지 않으므로 자체 UI의 중요한 요소는 안전 영역에 배치한다. 다만 일반 서드파티 앱의 사각 화면을 그대로 원형 전체에 채우면 모서리가 잘릴 수 있다. 임의 앱을 자동으로 원형 재배치하면서 전체 내용을 보존하는 기능은 일반 AOSP만으로 보장되지 않는다.

2026-10-14 · 포팅·UX·인증 검토 제안. 현행 AP는 QCS6490 Android이며, 차세대 AP는 그보다 상위 SoC를 적용한다. 구체 모델은 미정이고, 원형 패널은 지름 약 50cm를 검토 중이다. 실제 해상도·DSI mode·lane 속도·터치·패널 초기화는 미확정이다. 아래 480×480 수치는 설명용이며 선택 패널의 사양이 아니다. 제품 코드 변경·실기기 포팅은 이 문서 작업에 포함하지 않았다.

AP 분리/통합·Google Play 종합 검토 · 기존 OS 비교와 원형 UX

1. 사각 좌표·원형 가시 영역·해상도의 관계

예를 들어 480×480 좌표를 사용하는 지름 480px의 원형 패널이면, 디자인 도구의 사각 캔버스 위에 같은 크기의 원형 가시 영역을 표시하고 그 원을 기준으로 배치한다. 배경은 캔버스를 채워도 되고 문자·버튼은 원 안으로 넣는다. 패널/컨트롤러가 실제로 어떤 주소 공간과 마스크를 갖는지 사양으로 확인한다.

검은 여유 영역은 패널 안의 미사용 표시 영역이며 물리 베젤과 다르다. 단순 mask/clip은 밖의 내용을 숨길 뿐 내부로 이동시키지 않는다. 전체 앱을 축소하면 버튼·문자의 물리 크기가 줄고, 논리 화면을 바꾸면 앱 자체 레이아웃도 달라질 수 있어 별도 시험한다.

1.1 3번째 방식: Android에서 처음부터 원형 전용 UI 구성

일반 Android 앱을 만들되, 제품 화면 전체를 원형 전용 레이아웃으로 설계한다. 사각 좌표 공간은 유지한다. 예를 들어 480×480 패널이면 Activity의 콘텐츠 영역에서 실제 원 중심·반지름·가시 영역을 확인하고, 배경과 진행 링은 원 전체에 그리며 글자·버튼은 각 위치에서 허용되는 폭 안에 배치한다. 해상도를 낮추거나 Android 전체 프레임워크를 원형으로 다시 작성하는 방식이 아니다.

구현 구조

제품 Launcher / 전체화면 Activity
  └─ RoundScreen: 실제 콘텐츠 크기·원 중심·안전 영역 관리
       ├─ Canvas: 배경·외곽 진행 링·음성 파형
       ├─ RoundHeader: 상단의 좁은 폭에 맞춘 제목·상태
       ├─ RoundContent: 중앙의 넓은 폭에 맞춘 정보·선택 목록
       └─ RoundActions: 하단 높이를 고려한 확인·취소 버튼

신규 제품 UI는 Jetpack Compose의 일반 Android 구성요소와 커스텀 Layout으로 구현하는 안을 우선 검토한다. XML/View 기반이면 같은 규칙을 적용한 커스텀 ViewGroup으로 구성할 수 있다. 원형 디스플레이가 Wear OS를 사용해야 한다는 의미는 아니며, Wear 전용 라이브러리의 기기·입력 가정을 일반 AOSP 제품에 그대로 적용하지 않는다. Compose는 자식 요소의 크기 측정과 위치 배치를 커스텀 Layout에서 정의할 수 있다. Android 커스텀 레이아웃.

원형 레이아웃의 측정·배치

1. 실제 콘텐츠 영역을 얻는다. BoxWithConstraints 또는 커스텀 Layout의 constraints로 사용할 수 있는 크기를 얻는다. 패널의 가시 원과 앱 콘텐츠 좌표를 일치시키며, 시스템 bars·insets·회전·키보드가 공간을 바꾸면 원 중심과 배치 가능 영역을 다시 계산한다.
2. 공통 형상 값을 정의한다. 중심 (cx, cy), 반지름 R, 패널 비가시 영역과 조립·터치 여유를 반영한 안전 반지름 Rs=R−m을 화면 컴포넌트에 전달한다. 실제 가시 원이 정중앙·완전한 원인지 패널 사양으로 확인한다.
3. 위치와 높이로 가용 폭을 계산한다. 버튼이나 문장의 중심 높이만 보지 않고 전체 높이 중 원 중심에서 가장 먼 지점을 사용한다. 높이 범위가 yTop..yBottom이면 d=max(|yTop−cy|, |yBottom−cy|)이고, 중앙 정렬 요소의 최대 폭은 2√(Rs²−d²)다. d≥Rs이면 그 위치에는 양의 폭을 갖는 사각 요소를 배치할 수 없다.
4. 측정 결과에 맞춰 재배치한다. 제목 줄바꿈·버튼 높이·큰 글꼴로 높이가 바뀌면 허용 폭도 다시 계산한다. 폭이 부족하면 행 위치를 중앙으로 이동하거나 항목 수를 줄이고 다음 페이지·스크롤을 제공한다. 단순 축소로 터치와 가독성을 훼손하지 않는다.
5. 최종 사각 경계와 입력 영역을 확인한다. 중앙 정렬이 아닌 요소는 네 모서리 모두 원 안인지 검사한다. 표시 크기보다 큰 최소 터치 영역, 접근성 포커스, 애니메이션 이동 중 경계도 포함한다. clip은 시각적 마스크일 뿐 버튼을 안전 영역으로 옮기거나 입력 정책을 자동 완성하지 않는다.

다음은 중앙 정렬 사각 요소의 최대 폭을 계산하는 Kotlin 예시다. 입력과 반환값은 모두 동일한 단위로 사용한다. 실제 Layout의 측정은 px, 디자인 여백은 dp에서 px로 변환하고 텍스트 크기는 sp로 처리한다.

fun safeRowWidth(
    safeRadius: Float,
    centerY: Float,
    top: Float,
    bottom: Float
): Float {
    require(safeRadius >= 0f && bottom >= top)
    val farthestY = maxOf(
        kotlin.math.abs(top - centerY),
        kotlin.math.abs(bottom - centerY)
    )
    if (farthestY >= safeRadius) return 0f
    return 2f * kotlin.math.sqrt(
        safeRadius * safeRadius - farthestY * farthestY
    )
}

예시 480×480px, 안전 여백 16px이면 Rs=224px다. 중심이 화면 중앙보다 160px 아래에 있고 높이가 48px인 버튼은 가장 먼 높이가 184px이므로 허용 폭은 약 256px다. 버튼의 폭뿐 아니라 텍스트 줄바꿈·터치 영역이 그 안에 들어가야 한다. 코드와 수치는 레이아웃 설계 예시이며 제품 APK 구현·실기기 검증 결과가 아니다.

화면별 구성과 개발 범위

Canvas에 모든 버튼과 텍스트를 직접 그리기보다, 그래픽은 Canvas로 그리고 조작 요소는 Android/Compose 구성요소로 유지한다. 접근성 의미·포커스·터치·상태 처리를 함께 구현하기 좋다. 모든 공통 컴포넌트가 동일한 원형 측정 규칙을 사용하도록 디자인 토큰과 레이아웃 계층을 공유한다.

제품 앱 구현과 시스템 화면 포팅은 별도 작업이다. 제품 Launcher를 만들면 홈과 제품 기능 화면을 원형으로 구성할 수 있지만, 권한 팝업·IME·SystemUI·Settings·외부 앱은 다른 컴포넌트다. 해당 화면을 실제로 사용하는 흐름을 목록화하고 각 소유 컴포넌트의 수정 또는 안전한 표시 정책을 적용한다. 제3자 앱을 실행하면 그 앱의 UI가 제품 Launcher의 원형 레이아웃을 자동 상속하지 않는다.

적용 순서와 완료 기준

패널/BSP 출력·터치 좌표 확인 → 원형 형상과 공통 컴포넌트 구현 → 홈·음성·음악·설정·오류 화면 구현 → 시스템/외부 화면 연결 → 실제 패널 검증 순서로 진행한다. isScreenRound()는 앱에서 화면 형태를 조회하는 정보이며 배치 알고리즘을 대신하지 않는다. Configuration API.

완료 기준은 모든 필수 텍스트·버튼·확인창의 가시성과 조작 성공이다. 해상도·density·font scale·다국어·긴 텍스트·IME 표시·회전·애니메이션·외부 앱 전환을 시험한다. 원 밖의 숨은 버튼이 터치되거나 접근성 포커스를 받지 않는지도 확인한다. 디자인 도구의 원형 마스크와 에뮬레이터는 사전 확인에 사용하고 최종 판단은 실제 패널에서 한다.

2. 50cm 크기와 해상도·밀도는 각각 결정한다

지름 500mm에 480px이면 한 픽셀은 약 1.04mm라는 계산이다. 지름 480px 원에 내접하는 정사각형의 한 변은 약 339px, 실제 지름 500mm로 환산하면 약 354mm다. 크기는 충분해 보여도 가까운 거리의 작은 글자·곡선은 해상도가 제한할 수 있다. 특정 해상도를 권장 확정하는 대신 실제 거리에서 글자·터치·영상을 평가한다.

Android 배치는 dp/sp로 설계하되 실제 mm·시야각을 확인한다. 화면 밀도와 가시 영역은 해당 버전 CDD·DisplayMetrics 요구도 함께 만족해야 한다.

3. 포팅 계층과 실제 수정 범위

패널·터치·전원 회로
→ Kernel panel/touch driver · DTS/DTBO
→ Display HAL / Hardware Composer · vendor display stack
→ SurfaceFlinger · DisplayManager / WindowManager
→ SystemUI · Settings · PermissionController · IME · Launcher/제품 앱

AOSP 그래픽 구조를 기준으로 한 역할 구분이다. 원형이라는 이유로 Android 전체 프레임워크를 다시 작성하지 않는다. 패널/BSP 설정과 화면 배치 정책, 노출되는 시스템 UI를 조정한다. 새 패널이 기존 vendor stack에서 정상 동작하는지는 따로 확인해야 한다.

프레임버퍼가 사각이면 원형이라고 메모리가 자동 절감되지 않는다. 예시 480×480 RGBA8888 단일 비압축 버퍼는 921,600 byte(약 0.88 MiB)이고 실제 사용량에는 stride·버퍼 개수·레이어·텍스처가 추가된다.

4. 현행 AOSP의 설정 참고와 차세대 BSP 적용

아래는 현행 QCS6490 AOSP에서 확인한 설정 참고다. 차세대 상위 SoC의 파일 위치·리소스·vendor display 구현은 해당 BSP에서 다시 확인하며, 현행 소스를 그대로 적용하는 포팅 계획으로 해석하지 않는다.

QSSI/UM: frameworks/base/services/core/java/com/android/server/display/LocalDisplayAdapter.java
UM resources: frameworks/base/core/res/res/values/config.xml

• QSSI LA.QSSI.13.0.R1: LocalDisplayAdapter 664–667행 부근에서 config_mainBuiltInDisplayIsRound를 보고 DisplayDeviceInfo.FLAG_ROUND를 설정한다.
• UM LA.UM.9.14.1.R1: 같은 상대 경로의 547–550행 부근에서 동일 역할을 확인했다.
• UM framework resources: config_windowIsRound=false이며 config_mainBuiltInDisplayIsRound가 기존 bool을 참조한다.
• 앱 API: Configuration.isScreenRound()로 원형 정보를 조회하여 배치에 활용한다.

Configuration API는 앱의 화면 형태 판단 근거다. 플래그만 켜도 모든 사각 앱이 원형으로 자동 재배치되는 것은 아니다. 로컬 소스에는 에뮬레이터 원형 처리도 있으나 양산 패널 포팅을 에뮬레이터 속성으로 대신하지 않는다.

실제 적용 전에는 제품 타깃·framework 소스를 만드는 QSSI 입력·최종 제품 overlay/RRO·vendor panel DTS/DTBO를 확인한다. UM에 같은 소스가 있다고 그 파일 수정이 최종 이미지에 반영된다고 단정하지 않는다. 적용 후 최종 리소스·Display flag·앱 Configuration·터치 좌표·실제 화면을 함께 확인한다.

5. 원 안에서 잘리지 않는 배치 기준

반지름 R, 원 중심 기준 좌표 x/y, 안전 여백 m이면 점의 안전 조건은 x²+y² ≤ (R−m)²다. 문자·버튼은 중심점이 아니라 전체 사각 경계의 모서리를 확인한다. 전체 UI를 하나의 내접 사각형으로 제한할 수도 있고, 구성요소별 높이에 따라 폭을 달리할 수도 있다.

지름 480px, R=240px, 경계 오프셋 없음이라는 예시:

높이 y에서 폭은 2√(R²−y²)다. 조립 공차·패널 비가시 영역·터치 edge 오차를 더 반영한다. 가장자리 링은 장식·진행 표시에 활용하고 취소·긴급 조작·주요 선택은 읽고 누르기 쉬운 안쪽에 둔다. 색만으로 상태를 전달하지 않는다.

실제 구현에서는 원형 전용 layout/composable, 화면별 safe-region 계산, resize/font-scale 대응을 구성한다. 시스템이 주는 inset만으로 화면 전체의 원형 기하학이 처리된다고 가정하지 않고 각 요소의 표시·터치 경계를 검증한다.

6. 자체 UI와 외부 앱은 서로 다른 전략

일반 앱의 안전한 사각 표시는 검토할 framework/vendor 통합안이다. 단순히 Launcher에 앱을 작은 View로 넣거나 overlay로 덮으면 된다는 구현 완료 설명이 아니다. 실제 app task/window의 영역·합성·입력 변환·insets·IME·시스템 dialog·보호 콘텐츠를 일관되게 처리해야 한다. resize 거부·고정 방향 앱과 외부 인증 화면도 시험한다.

자체 원형 홈과 외부 앱의 안전한 사각 표시를 전환하려면 논리 display/task 구성과 화면 상태 복원, 앱이 조회하는 metrics를 설계한다. 필요한 AOSP/vendor 변경과 certification 적용 여부를 공급사 검토로 확정한다. 이 방식에 원 주변 여백이 남는 것을 제품 UX가 허용해야 한다.

핵심 제약은 임의 앱 + 원 전체 채움 + 모든 내용 보존 + 앱 수정 없음을 동시에 자동 보장할 수 없다는 것이다. 글자·버튼의 의미를 framework가 일반적으로 파악해 재배치하지 않는다. 외부 앱 확장이 필수이면 원형화 가이드와 호환성 검증 정책을 제품 플랫폼의 일부로 운영한다.

7. 시스템 화면은 담당 컴포넌트별로 보완

담당 컴포넌트는 버전/BSP별로 확인한다. 일반 앱 overlay는 시스템 소유 기능을 대체하지 않으며 보안/권한 UI를 감추는 방식으로 원형화를 해결하지 않는다. 표준 API 동작과 사용자가 이해할 수 있는 권한·복구 흐름을 유지한다.

8. Google Play를 고려한 원형 화면의 선행 검토

약 50cm(19.7인치) 표시 규모는 CDD Handheld의 4–8인치 분류 조건을 그대로 적용할 수 없다. 적용 가능한 기기 유형을 실제 제품 용도·입력·화면과 대조하고 OEM/Google의 제품 경로 확인을 받아야 한다. 원형 표시 문제를 해결해도 그 사실만으로 Play/GMS 가능성이 확정되는 것은 아니다.

Android 16·17 CDD 7.1.1.1은 일반 UI 모드 화면에 대해 모서리 반경 또는 논리 화면 모서리의 가시성 조건을 두고, 보고하는 dp 크기와 실제 display metrics도 규정한다. 물리 원형 패널에 사각 논리 화면을 꽉 채워 모서리를 숨기는 구조는 충돌 위험이 있다. 이는 공개 조항에 따른 설계 해석이며 제품별 인증 판정은 아니다.

검토해야 할 세 가지 제품안은 다음과 같다.

1. 원형 전용 제품 UI + 일반 앱의 안전한 사각 표시: 물리 원형은 유지하고 일반 앱 경로는 전체 내용을 보존. 최소 dp·밀도·시스템 화면·터치·기기 유형/GMS 적용을 확인한다.
2. 원형 최적화 앱만 제공: 파트너 앱/승인 SDK 중심으로 UX 통제. 자유로운 일반 앱 확장 요구와 차이가 있어 제품 의사결정 필요.
3. 일반 앱용 추가 사각 디스플레이/화면 경로: 하드웨어·UX 비용 증가. multi-display·default display·설정·Play/기기 유형까지 별도 확인.

Watch/Wear OS 모드를 원형이라는 이유로 선택하지 않는다. 디스플레이 지름이 약 50cm인 제품의 실제 용도·기기 유형을 확인하고, Wear OS 앱 생태계와 일반 Android 앱 생태계를 구분한다. Wear UI의 배치 원리는 참고할 수 있지만 일반 AOSP에 Wear OS/GMS를 제공하는 수단이 아니다.

패널 확정 전 BSP/ODM·인증 담당에게 물리 원형, 일반 앱의 논리 영역, dp/DPI·입력, 출시 Android 버전·판매 국가를 제시하고 적용 경로를 확인한다. CTS 통과와 GMS/Play 라이선스는 별도다.

근거: Android 16 CDD §7.1, Android 17 CDD §7.1, 호환성 프로그램, GMS.

9. 단계별 포팅 산출물과 완료 기준

검증은 실제 패널의 전체 가시 영역과 터치 영역으로 수행한다. 에뮬레이터, SVG, 앱 screenshot, 빌드 성공은 설계/정적 증거이며 패널 포팅 완료 증거가 아니다. 하드웨어 검증 전에는 native mode·DSI timing·드라이버 파일명을 확정하지 않는다.

10. 최종 방향

자체 제품 UI는 원형 전체를 활용하고, 일반 외부 앱은 전체 조작이 보존되는 표시 경로를 제공하는 방향을 권고한다. UI 전용 round flag와 패널 포팅만으로 제품이 완성되지 않으므로 시스템 화면·입력·외부 앱·인증을 묶어서 진행한다.

약 50cm라는 크기만으로 앱 잘림이 해결되지는 않는다. 높은 해상도와 큰 물리 크기는 정보/터치 여유를 줄 수 있지만 원형 밖의 모서리는 여전히 보이지 않는다. 앱 확장성과 Play가 중요하면 원형 물리 형태와 일반 앱 논리 화면의 양립 가능성을 먼저 확인하고 패널·BSP를 선택한다.

Connections

• 차세대 AP 분리/통합·인증 검토
• 기존 Android/Linux·Qt·원형 UX 비교
• 플랫폼 벤더 범위
• Android graphics
• Configuration.isScreenRound
• Android Compatibility