Android 11의 최고의 기능 중 3가지가 모든 스마트폰과 태블릿에 표시되지는 않습니다. 이는 Google이 이러한 기능을 의무화하지 않기 때문입니다.
Google은 매년 새로운 버전의 Android 운영 체제를 출시합니다. Google은 지난 2월 첫 번째 Android 11 개발자 프리뷰를 출시한 후 지난 몇 달 동안 두 번째, 세 번째, 네 번째 개발자 프리뷰를 출시했습니다. 이달 초 구글은 최초의 Android 11 베타 사용자가 즐길 수 있는 최고의 기능과 개발자가 구현할 수 있는 최고의 기능에 대해 심도 있게 이야기했습니다. 그러나 이제 우리는 Android 11의 주요 기능 중 3가지를 모든 Android 기기에서 사용할 수는 없다는 사실을 알게 되었습니다.
그것이 어떻게 가능한지 이해하려면 안드로이드 OS가 구글에서 스마트폰 기기 제조사에 어떻게 배포되는지 간략하게 설명해야 한다. 안드로이드는 오픈 소스 운영 체제 Apache 2.0에 따라 라이센스가 부여되었습니다. 즉, 인디 개발자부터 대기업에 이르기까지 누구나 자신의 장치에서 OS를 자유롭게 수정하고 배포할 수 있습니다. 구글이 안드로이드 11에 공개한 새로운 OS 기능의 대부분은 스마트폰이 지원하는 안드로이드 오픈소스 프로젝트(AOSP)의 일부가 될 것이다. 장치 제조업체는 자체 소프트웨어를 기반으로 하지만 앞서 언급한 것처럼 Apache 2.0 라이센스를 사용하면 누구든지 보이는 대로 소프트웨어를 수정할 수 있습니다. 맞다. Android 기기 간의 API 및 플랫폼 동작의 일관성을 유지하기 위해 Google은 Google 모바일 서비스 배포를 번들로 묶습니다. Google Play 스토어 및 Google Play 서비스와 같은 애플리케이션 및 프레임워크) 기기가 Google의 규칙을 준수하도록 요구하는 라이선스 계약이 있는 경우 "Android 호환성 프로그램"(다른 요구 사항 중). Android 호환성 프로그램은 여러 자동화된 테스트 모음과 Android에 열거된 규칙 집합으로 구성됩니다. 호환성 정의 문서 (CDD).
CDD에 Google은 기기 제조업체가 구현해야 하는 소프트웨어 및 하드웨어 기능을 나열합니다. 구현하는 것을 "강력히 권장"하거나 구현하지 않는 것이 "해서는 안되는" 기능입니다. 기능이 '구현해야 함'으로 나열된 경우 기기 제조업체는 해당 기능을 추가해야 합니다. 그렇지 않으면 기기에 Google 앱을 출시할 수 없습니다. 기능이 '구현하면 안 됨'으로 나열되어 있으면 기기 제조업체에서 해당 기능을 추가할 수 없거나 Google 앱을 번들로 묶을 수 없습니다. 마지막으로 기능이 'STRONGLY RECOMMENDED'로 표시되면 해당 기능을 구현할지 여부는 기기 제조업체에 달려 있습니다. CDD는 새로운 Android 버전이 공개된 후 매년 공개되기 전부터 끊임없이 변화하는 문서입니다. Google은 기능을 제거하고, 언어를 더 명확하게 변경하고, 파트너의 피드백을 기반으로 요구 사항을 완화하기 위해 문서를 자주 업데이트합니다. 그러나 Google이 특정 Android 버전에 대한 CDD를 공개하면 해당 Android OS 버전을 실행하는 Google 인증 기기에 대해 해당 요구사항이 확정됩니다.
Android 11 CDD는 올해 말, 아마도 9월 초까지 공개되지 않을 것입니다. 그러나 개발자 @삭제 CDD에 대한 변경 사항을 자세히 설명하는 문서의 시험판 사본을 공유하여 Google이 생태계 전반에 걸쳐 Android 11을 어떻게 형성하고 있는지 미리 살펴볼 수 있습니다. CDD에 대한 60개 이상의 변경 사항 중 대부분은 사용자에게 그다지 흥미롭지 않습니다. 기기 제조업체는 특정 API를 구현하고, 특정 기능을 선언하고, 특정 커널을 구현해야 합니다. 특징. 그러나 CDD의 변경 사항 중 3가지가 Android 11의 가장 흥미로운 기능 중 일부와 관련이 있기 때문에 우리의 관심을 끌었습니다. 우리가 밝혀낸 내용은 다음과 같습니다.
장치 제어
기기 제어는 스마트 홈 자동화 제어를 전원 메뉴에 표시할 수 있는 Android 11의 기능입니다. 수십 가지의 다양한 스마트 홈 앱을 열지 않고도 조명을 끄고, 차고 문을 열고, 진공청소기를 작동하고, 집 온도를 변경하는 등 다양한 작업을 수행할 수 있습니다. Google은 스마트 홈 앱 개발자가 전원 메뉴에 컨트롤을 표시하는 데 사용할 수 있는 API를 추가했습니다. 우리는 이것이 정말 좋은 기능이라고 생각합니다. 마침내 스마트폰을 스마트 홈으로 가져왔습니다.. 불행하게도 OEM이 이를 실제로 구현해야 한다는 요구 사항은 없습니다. OEM이 기능이 부족하다고 생각하거나 다른 경로로 가고 싶어하는 경우(예: 스마트한 기능만 허용) 자체 생태계에 있는 장치의 홈 제어), 간단히 장치에 대한 지원을 비활성화할 수 있습니다. 통제 수단.
Google은 2020년 2월 25일 CDD에 장치 제어를 처음 추가했을 때 섹션 2.2.3 - 휴대용 소프트웨어 요구 사항에 "필수" 요구 사항을 추가하여 이를 포함하도록 의무화했습니다. 그러나 2020년 5월 20일에 Google은 제안된 'MUST'를 삭제하기 위해 텍스트를 업데이트했습니다. 새로운 섹션 3.8.16 - 장치 제어에서는 기능을 구현하는 방법을 간략하게 설명하지만 실제로 구현을 요구하지는 않습니다! OEM이 이 멋진 기능을 비활성화하지 않기를 바라지만, OEM이 이 기능을 비활성화했는지 여부를 알 수 있는 방법은 없습니다. Android 11을 기반으로 구축된 자체 Android 버전을 공개할 준비가 되어 있습니다. 이는 Android 11에서 몇 달이 지나야 공개됩니다. 지금.
제안된 섹션 3.8.16(신규) - 장치 제어(2020년 5월 20일 업데이트됨)
3.8.16 장치 제어
Android에는 개발자가 사용자의 빠른 상태 및 작업을 위한 장치 컨트롤을 게시할 수 있도록 하는 ControlsProviderService 및 Control API가 포함되어 있습니다.
3.8.16.1 장치 제어 사용자 어포던스
장치가 장치 제어를 구현하는 경우 다음을 충족해야 합니다.
- [C-1-1] android.software.controls.feature 플래그를 TRUE로 보고해야 합니다(MUST).
- [C-1-2] android.service.controls를 통해 타사 앱에 등록된 컨트롤에서 사용자 즐겨찾기를 추가, 편집, 선택, 조작할 수 있는 기능을 사용자 어포던스에 제공해야 합니다(MUST). ControlsProviderService 및 android.service.controls. 제어 API.
- [C-1-3] 런처의 세 가지 상호작용 내에서 이 사용자 어포던스에 대한 액세스를 제공해야 합니다(MUST).
- [C-1-4] 이 사용자 어포던스에서 android.service.controls를 통해 제어 기능을 제공하는 각 타사 앱의 이름과 아이콘을 정확하게 렌더링해야 합니다(MUST). ControlsProviderService API는 물론 android.service.controls에서 제공하는 지정된 아이콘, 상태 텍스트, 장치 유형, 이름, 구조, 영역, 사용자 정의 색상 및 자막도 포함됩니다. 제어 API
반대로, 기기 구현이 이러한 제어를 구현하지 않는 경우
- [C-2-1] ControlsProviderService 및 Control API에 대해 Null을 보고해야 합니다(MUST).
더 읽어보세요
알림의 대화
iOS에 비해 Android의 가장 큰 장점 중 하나는 전자가 알림을 처리하는 방식입니다. Android 11에서는 '대화' 기능이 도입되면서 사용성 격차가 더욱 커질 것입니다. Android 11에서는 알림 메시징 앱의 항목은 함께 그룹화되어 있으며 대부분의 다른 항목 위에 있는 알림 패널의 별도 섹션에 표시됩니다. 알림. 이를 통해 보류 중인 다른 모든 알림을 스크롤하지 않고도 메시지를 빠르게 확인하고 응답할 수 있습니다. 안타깝게도 알림에 대한 이 멋진 변경 사항은 모든 장치에서 사용 가능하지 않을 수 있습니다. Google은 OEM에게 "미리 대화 알림을 그룹화하고 표시할지 여부"를 선택할 수 있는 옵션을 제공합니다. 비대화 알림." OEM은 알림 패널을 자주 맞춤설정하므로 Google이 OEM에게 알림 패널을 제공하는 것은 놀라운 일이 아닙니다. 여기서 선택. 그럼에도 불구하고 Google이 Android 11의 알림에 더 많은 일관성을 적용하지 않는 것은 불행한 일입니다.
섹션 3.8.3.1에 대한 제안된 변경 사항 - 알림 표시(2020년 4월 8일 업데이트됨)
타사 앱이 사용자에게 중요한 이벤트를 알리도록 허용하는 기기 구현은 다음을 충족해야 합니다.
...
Android R에는 알림 관리자를 사용하는 알림인 대화 알림 지원이 도입되었습니다. MessageStyle은 게시된 사람 바로가기 ID를 제공합니다.
장치 구현은 다음과 같습니다.
- [H-SR] 대화하지 않기 전에 대화 알림을 그룹화하고 표시할 것을 적극 권장합니다(STRONGLY RECOMMENDED). 지속적인 포그라운드 서비스 알림을 제외한 알림 및 중요도: 높음 알림.
대화 알림이 별도의 섹션으로 그룹화되는 경우 기기 구현
- [H-1-8] 진행 중인 포그라운드 서비스 알림 및 중요도: 높은 알림을 제외하고 비대화 알림보다 먼저 대화 알림을 표시해야 합니다(MUST).
장치 구현은 다음과 같습니다.
- [H-SR] 대화 알림에서 다음 작업에 대한 액세스를 제공할 것을 적극 권장합니다. 앱이 버블에 필요한 데이터를 제공하는 경우 이 대화를 버블로 표시합니다.
AOSP 구현은 기본 시스템 UI, 설정, 실행기를 통해 이러한 요구사항을 충족합니다.
더 읽어보세요
IdentityCredential - 모바일 운전면허증
마지막으로 제가 가장 기대하는 기능 중 하나는 IdentityCredential API입니다. 작년에 자세히 설명했듯이, IdentityCredential API는 애플리케이션이 모바일 운전면허증과 같은 신원 문서를 기기에 저장할 수 있도록 설계되었습니다. 전 세계 여러 국가(및 일부 미국 주)에서는 이미 시민들이 운전 면허증을 모바일 앱에 저장할 수 있도록 허용하고 있습니다. 그러나 Google은 데이터를 안전한 환경에 오프라인으로 저장하여 이를 더욱 안전하게 만들기 위해 노력하고 있습니다.
Android 11의 소스 코드에는 IdentityCredential API(개발자가 휴대전화의 ID 문서를 저장하기 위해 호출하는 API)가 포함되어 있습니다. 보안 환경) 및 IdentityCredential HAL(휴대폰의 보안 환경과 인터페이스)이 필요하지만 OEM은 다음을 수행할 필요가 없습니다. 그것들을 구현하십시오. Google은 2020년 1월 10일 CDD에 IdentityCredential을 포함할 것을 처음 제안했을 때 이를 요구 사항으로 나열했습니다. 그러나 2020년 3월 18일에 이 요구 사항을 완화했으며 이제 OEM이 이 기능을 지원할 것을 강력히 권장합니다. Google이 이 요구 사항을 완화한 것은 놀라운 일이 아닙니다. 신뢰할 수 있는 실행 환경에 영향을 미치는 변경 사항을 추가하려면 OEM의 노력이 필요합니다. OEM이 이러한 변화에 대비하는 데 더 많은 시간이 필요할 수도 있습니다. 하지만 사용자 입장에서는 특정 Android 11 스마트폰이 휴대폰의 보안 환경에 모바일 운전면허증을 안전하게 저장하는 것을 지원한다는 보장이 없다는 의미입니다.
Android 11 장치에서 IdentityCredential 시스템을 널리 채택하는 것을 막는 기술적 제한이 없다는 점에 유의해야 합니다. IdentityCredential 시스템을 구현하기 위한 요구 사항 중 하나는 장치에 Trusted Execution이 있어야 한다는 것입니다. "신뢰할 수 있는 애플리케이션"이 저장된 ID와 상호 작용하는 환경(TEE) 또는 전용 보안 프로세서 서류. Android 7.0 Nougat 이후 Google은 모든 최신 Android 기기에 "격리된 실행 환경"을 지원하도록 요구했습니다. 섹션 2.2.5 - CDD의 보안 모델). ARM 프로세서가 탑재된 장치에는 일반적으로 ARM 프로세서가 탑재되어 있습니다. 트러스트존 TEE이며 Google은 신뢰할 수 있는 OS TrustZone에서 실행됩니다. TEE가 있으면 IdentityCredential 시스템을 지원하기에 충분하지만 자격 증명이 내장된 보안 CPU(예: 일부 Qualcomm Snapdragon 프로세서의 보안 처리 장치) 또는 별도의 보안 CPU(예: 구글의 타이탄 M 또는 삼성의 새로운 보안 칩). 특히 개별 보안 CPU가 있는 장치는 IdentityCredential 시스템의 "직접 액세스 모드" 기능을 지원할 수도 있습니다. 이를 통해 장치에 기본 OS를 부팅할 만큼 충분한 전력이 남아 있지 않은 경우에도 사용자가 자신의 신원 문서를 불러올 수 있습니다.
제안된 섹션 9.11.3(신규) - 신원 자격 증명(2020년 3월 18일 업데이트됨)
ID 자격 증명 시스템을 사용하면 앱 개발자가 사용자 ID 문서를 저장하고 검색할 수 있습니다.
장치 구현:
- [C-SR]은 신원 자격 증명 시스템을 구현할 것을 적극 권장합니다.
기기 구현이 ID 사용자 인증 정보 시스템을 구현하는 경우 다음을 충족해야 합니다.
- [C-0-1] null이 아닌 값을 반환해야 합니다(MUST). IdentityCredentialStore#getInstance() 방법.
- [C-0-2] 신뢰할 수 있는 서비스와 통신하는 코드로 `android.security.identity.*` API를 구현해야 합니다(MUST). TEE(신뢰할 수 있는 실행 환경) 또는 전용 보안 환경에서 실행되는 애플리케이션 프로세서. 신뢰할 수 있는 애플리케이션은 다음과 같이 구현되어야 합니다. 신뢰할 수 있는 컴퓨팅 기반 ID 자격 증명 시스템의 경우 Android 운영 체제가 포함되어 있지 않습니다.
더 읽어보세요
Google은 또한 개발자가 ID를 안전하게 저장하기 위한 지원을 더 쉽게 추가할 수 있도록 IdentityCredential Jetpack 라이브러리를 개발 중입니다. 하지만 진짜 어려운 점은 정부가 정부 ID를 안전하게 저장하기 위해 이 API를 사용하여 앱을 승인하도록 하는 것입니다. 에 따르면 엔가젯, 한국은 최근 모바일 앱에 운전면허증을 저장하는 기능을 지원하기 시작했으며 이 기술에 대한 수용이 증가하기 시작했습니다. 나는 이것이 어디로 가는지 보고 신난다. 왜냐하면 밖에 나갈 때 가지고 다닐 물건이 하나도 줄어들 것이기 때문이다.
우리가 입수한 문서에는 변경이 이루어진 날짜까지 CDD의 변경 사항이 나열되어 있습니다. 최신 변경 사항은 2020년 6월 10일에 이루어졌으므로 현재 보유하고 있는 문서가 상당히 최신 상태입니다. Google이 이러한 변경 사항을 취소하고 Android 11이 공개되기 전에 모든 요구 사항을 다시 만들 수도 있지만 Google이 갑자기 CDD를 만들지는 의문입니다. 더 절박한. 이러한 변경 사항은 아직 계획되지 않은 경우 이러한 기능을 다시 구현해야 하는 OEM의 피드백으로 인해 완화되었을 가능성이 높습니다. 이를 위해서는 시간, 노력, 비용이 필요하므로 Google 이외의 기기용 Android 11 출시가 더욱 지연될 뿐입니다. 하지만 Google에서 이러한 기능을 다시 한 번 요구하게 되면 XDA 포털에 업데이트를 게시할 것입니다.