안드로이드14. 지금까지 가능성 높은 소식들

출처는 Mishaal Rahman (esper.io) 에서 가져왔습니다.

안드로이드 14가오고있다 : 지금까지 우리가 알고있는 것은 다음과 같습니다. (esper.io)

Android 14 is coming: Here’s what we know so far

The next big Android update will be Android 14, set for release in 2023. Here are all the changes we're expecting to see.

blog.esper.io

1. 예측 뒤로가기 제스처("백투홈" 애니메이션)

Android의 뒤로 제스처를 사용할 때 작업이 앱을 종료할지 또는 사용자를 앱 내의 이전 화면으로 이동할지 여부가 사용자에게 항상 명확하지는 않습니다. 이는 일반적으로 뒤로 제스처가 수행 될 때 어떤 일이 발생할지 나타내는 피드백이 없기 때문입니다. 앱은 다시 누르기 이벤트를 처리하고 사용자에게 "종료"할 것인지 묻는 피드백(예: 대화 상자 형식)을 제공할 수 있지만 많은 앱에서는 이 작업을 수행하지 않습니다.

앱은 백 프레스의 동작을 제어하거나 사용자 정의 백 스택을 구현할 수 있기 때문에 시스템 자체가 뒤로 제스처가 수행 될 때 어떤 일이 발생하는지 알 수있는 방법이 없습니다. 이 문제를 해결하기 위해 Android는 사용자에게 일종의 피드백을 제공 할 수 있도록 어떤 일이 일어날 지 "예측"할 수 있어야합니다.

이것이 Google이 Android 13에서 예측 백 제스처 탐색을 도입 한 이유입니다. 이 기능은 사용자가 앱을 종료하는 뒤로 제스처를 수행할 때 런처의 시각적 미리 보기를 표시하여 앞서 언급한 모호성을 수정합니다. Google은이 시각적 미리보기를 "백투홈"애니메이션이라고 부르며 Android 13의 AOSP Launcher3의 일부입니다.

요약)

안드로이드의 뒤로가기 제스처를 사용할때 어떤 일이 발생할지 나타내는 피드백이 없었다.
안드로이드14에선 일종의 피드백을 제공할수있도록 어떤 일이 일어날 지 예측 할수있게 해줘야한다.
그리하여 뒤로가기 제스처를 수행할때 시각적 미리 보기 애니메이션을 표시하여 위의 문제를 해결하였다.
안드로이드13의 AOSP 런처3에서 시각적미리보기를 백투홈 애니메이션이라고 부른다.

플랫폼 수준에서 이 기능은 이미 작동하지만 새 뒤로 탐색 API를 활용하도록 앱을 업데이트해야 합니다. Google은 예측 백 제스처를 지원하도록 업데이트되지 않은 앱을 사용할 때 사용자가 깨진 백 네비게이션을 경험할 수 있다고 경고하므로 개발자는 가능한 한 빨리 앱을 업데이트해야합니다.

개발자에게 앱을 업데이트 할 시간을 제공하기 위해 Google은이 기능의 출시를 Android 14까지 연기하기로 결정했습니다. Android 13에서는 앱이 옵트인하고 사용자가 "예측 백 애니메이션" 개발자 옵션을 활성화하지 않는 한 예측 백 제스처가 사용되지 않습니다. 그러나 Android 14부터는 API 레벨 34 이상을 대상으로 하는 앱에 대해 기본적으로 새로운 백 디스패치 동작이 활성화됩니다.

2. 위성 연결?

T-Mobile과 SpaceX가 저지구 궤도 위성을 사용하여 "이전에는 전통적인 세포 신호로는 도달 할 수 없었던 원격 위치"로 범위를 확대한다는 공동 발표에 이어 안드로이드의 SVP 인 Hiroshi Lockheimer는 트위터에 "다음 버전의 Android에서이 모든 것을 가능하게하는 파트너를 지원하게되어 기쁩니다!"

-> 안드로이드14부터는 위성 연결(스페이스X의 그것)이 지원될것으로 보입니다.

(19) Hiroshi Lockheimer 님의 트위터: "Wild to think about user experiences for phones that can connect to satellites. When we launched G1 in '08 it was a stretch to get 3G + Wifi working. Now we're designing for satellites. Cool! Excited to support our partners in enabling all of this in the next version of Android!" / 트위터 (twitter.com)

트위터에서 즐기는 Hiroshi Lockheimer

“Wild to think about user experiences for phones that can connect to satellites. When we launched G1 in '08 it was a stretch to get 3G + Wifi working. Now we're designing for satellites. Cool! Excited to support our partners in enabling all of this in th

twitter.com

3. Android Resource Economy

앱 개발자에게 가장 큰 과제 중 하나는 특히 백그라운드 작업과 관련하여 브랜드별 특이성을 다루는 것입니다.
많은 브랜드가 매우 제한적이지만 더 나쁜 것은 완전히 문서화되지 않은 백그라운드 앱 관리 기능을 구현합니다.
Google은 OEM이 AOSP에 있는 기능을 출시하거나 최소한 확장하기를 희망하면서 새로운 백그라운드 앱 관리 기능을 도입하여 이 문제를 해결하기 위해 천천히 노력하고 있습니다.

Android 13에서는 앱이 백그라운드에서 작업을 수행하는 방식에 여러 가지 변경 사항이 도입되었지만 가장 중요한 변경 사항 중 하나는 출시되지 않았습니다. The Android Resource Economy의 약자 인 TARE는 시스템이 백그라운드 작업을 관리하는 방법에 대한 주요 재고입니다. Android 13에서는 기본적으로 비활성화되어 있지만이를 활성화하기위한 토글은 개발자 옵션에 묻혀 있습니다. 아마도 이 기능은 Android 13 용 개발이 동결 될 때까지 준비되지 않았지만 Google이 Android 14에서이를 활성화 할 가능성이 있습니다.

그렇다면 TARE란 무엇입니까? TARE는 Android의 JobScheduler 및 AlarmManager API를 사용하여 대기 중인 작업을 실행할 때 시스템의 논리를 조정합니다. 앱이 나중에 일부 작업을 수행하려고 할 때마다 이러한 API(또는 WorkManager와 같은 상위 수준 래퍼) 중 하나를 사용하여 작업을 대기열에 넣습니다. 사용되는 API와 전송되는 매개 변수를 기반으로 시스템은 설정된 시간, 특정 시간 또는 앱의 요청을 충족하고 장치의 배터리에 최적인 시간에 작업을 실행합니다. 문제는 TARE 이전에 안드로이드는 언제 작업을 실행할지 지능적으로 결정할 뿐 얼마나 많은 작업을 실행해야하는지 지능적으로 결정하거나 특정 작업에 더 많은 중요성을 부여하지 않는다는 것입니다.

TARE에서 안드로이드는 수요와 공급의 기본 경제 원칙을 배경 작업에 적용합니다. Android는 "Android 리소스 크레딧"(ARC) TARE 대리자를 앱에 공급하여 대기열에 작업을 "지출"할 수 있습니다. 주어진 순간에 "순환"중인 ARC의 양은 총 작업을 수행 할 수있는 양을 제한하도록 변경할 수 있습니다. 배터리가 "만족"될 때, 즉. 가득 차면 ARC의 총 수가 최대치에 있으며 이를 "소비 제한"이라고합니다.

작업 대기열의 "생산 비용"(CTP)은 수행되는 작업 유형에 따라 다릅니다. 리소스를 많이 사용하는 작업이 많을수록 일반적으로 대기열에 더 많은 ARC가 필요합니다. 시스템은 사용자가 앱을 열기 위해 알림을 탭하는 경우와 같이 좋은 결과를 위해 더 많은 ARC를 앱에 보상할 수 있습니다. 포커스가 있는 앱, 포그라운드 서비스 및 시스템 중요 프로세스를 제외하면 앱에 사용할 ARC가 부족하면 백그라운드 작업을 대기열에 넣을 수 없습니다. 앱은 사용 가능한 ARC를 기반으로 신중하게 작업을 선택하도록 설계되어야 하며, 시스템은 CTP 순서대로 작업을 실행하여 "이익"을 극대화하도록 설계되었습니다.

TARE가 여전히 미세 조정되고 있다고 생각하지만 Android 14가 출시되기 전에 폐기 될 수 있습니다. 그러나 TARE가 Android 14에 맞춰 준비가되면 Google이 백그라운드 작업에 얼마나 큰 영향을 미치는지 고려하여 앱을 조정할 수있는 유예 기간을 개발자에게 제공한다면 놀라지 않을 것입니다.

4. AV1 디코딩에 대한 필수 지원

Google은 AV1의 가장 큰 후원자 중 하나이며, Google이 속한 오픈 미디어 연합 (Alliance for Open Media)이 개발 한 로열티가없고 고효율 비디오 압축 알고리즘입니다. 조금 건너뛰고..

여러 실리콘 공급 업체 (특히 삼성, MediaTek 및 Google 자체)는 AV1 하드웨어 디코딩을 지원하는 제품을 출시했습니다. 퀄컴의 다가오는 주력 스냅드래곤 칩셋은 AV1에 대한 지원을 추가한다는 소문이 돌았고, AV1 디코딩을 지원하는 제품을 보유한 주요 안드로이드 SoC 제조업체 목록을 마무리했다. 2023년에 새로 출시된 대부분의 플래그십 티어 및 상위 중급 핸드헬드 장치는 AV1 디코딩을 지원해야 하며, 2024년에만 그 수가 증가하고 있습니다. 그럼에도 불구하고 AV1 지원없이 내년에 출시 될 장치가 상당히 많기 때문에 모든 장치가 AV1 디코딩을 지원해야한다는 Android 14의 요구 사항은 약간 조급한 느낌입니다.

5. ID 자격 증명 HAL에 대한 필수 지원

Android의 ID 자격 증명 API는 모바일 운전 면허증과 같은 사용자 ID 문서를 안전하게 저장하는 인터페이스를 제공합니다. TEE(신뢰할 수 있는 실행 환경)가 있는 장치는 이 하드웨어를 지원하지 않는 장치보다 ID 문서를 훨씬 더 안전하게 저장할 수 있지만 이렇게 하려면 HAL(ID 자격 증명 하드웨어 추상화 계층)을 구현해야 합니다.

현재 Google의 Pixel 기기만 ID 자격 증명 HAL을 구현했습니다. ID 자격 증명 API에 대한 하드웨어 지원을 확장하기 위해 Google은 Android 13으로 시작하는 칩셋이 ID 자격 증명 HAL을 지원하도록 요구할 계획이었습니다. 이것은 안드로이드 13 위에 구축 된 BSP로 출시되는 차세대 칩셋을 갖춘 미래의 주력 장치가 ID 자격 증명 HAL을 지원하는 픽셀에 합류 할 것임을 의미했을 것입니다. Google은 기기 공급업체 소프트웨어의 규정 준수를 검증하는 자동화된 테스트 스위트인 공급업체 테스트 스위트(VTS)의 새로운 테스트를 통해 이 요구 사항을 적용할 계획이었습니다.

그러나이 요구 사항은 5 월에 병합 된 코드 변경에 따라 Android 14에 적용되었습니다.이 요구 사항이 폐기되거나 더 이상 지연되지 않는 한, Android 14 지원으로 시작하는 칩셋은 ID 자격 증명 HAL을 지원해야합니다. 기기를 Android 14로 업그레이드하는 OEM은 GRF(Google Requirements Freeze)로 인해 ID 자격 증명 HAL을 구현할 필요가 없습니다.

6. EROFS로 포맷된 읽기 전용 파티션

EROFS는 원래 Huawei가 모바일 장치 용으로 개발 한 읽기 전용 파일 시스템입니다. Huawei가 배포 한 후 다른 여러 Android OEM은 EXT4보다 압축시 얼마나 효율적인지 때문에 EROFS에서 장치의 읽기 전용 파티션을 포맷하기 시작했습니다. 화웨이의 EROFS 용 커널 드라이버는 버전 5.4의 메인 라인 리눅스 커널의 일부가되었으며 안드로이드 공통 커널의 android11-5.4 및 이후 지점에서 사용할 수 있습니다.

안드로이드 13을 개발하는 동안 Google은 EROFS 이미지를 update_engine, A / B 및 가상 A / B OTA AKA "원활한 업데이트"의 사용자 공간 프로세스로 구문 분석하는 지원을 추가했습니다. 구글은 또한 EROFS로 포맷된 대부분의 프로젝트 메인라인 모듈의 고기인 APEX 이미지 페이로드를 배포하는 실험을 시작했다.

EXT4에 비해 EROFS의 이점을 감안할 때 Google은 OEM이 모든 읽기 전용 파티션에 사용하도록 권장하고 있습니다. Google은 원래 Android 13으로 시작하는 모든 장치에 EROFS 형식의 읽기 전용 파티션을 요구할 계획이었지만 이러한 요구 사항을 완화하고 Android 13 출시 장치가 EROFS에 대한 커널 지원과 함께 제공되도록 요구하는 것만으로 결정했습니다. 구글이 안드로이드 14에 대한 EROFS 의무를 다시 검토 할 가능성은 있지만, 이것은 여전히 남아 있습니다.

요약)

안드로이드13부터 EXT4 -> EROFS로 읽기전용 파티션으로 바꿀것을 요구할 예정이었으나 함께 제공되도록 요구사항을 변경했습니다. 안드로이드14에선 다시 EROFS 를 강제하도록 다시 컴토 할 가능성이 있습니다.

7. Armv9 CPU가 장착 된 장치는 64 비트 전용 Android와 함께 제공되어야 할 수도 있습니다.

iOS는 2017 년에 32 비트 앱에 대한 지원을 종료했지만 Android는 여전히 32 비트 앱에 대한 지원을 중단하지 않았습니다. 이것은 Armv8 ISA가 2011 년에 AArch64 실행 모드로 출시되었고 Android 5.0 Lollipop이 2014 년에 64 비트 앱에 대한 지원을 도입 했음에도 불구하고 있습니다. 시장에 나와있는 대부분의 Android 기기는 32 비트 ABI와 함께 제공되며 OEM은 32 비트 지원없이 Android를 구축 할 수 있습니다 (그리고 빌드를 인증 할 수있는 경우 Android 13을 사용).

안드로이드가 32 비트 앱 지원을 중단 할 때 iOS보다 훨씬 뒤쳐진 이유는 32 비트 앱이 중국과 같은 특정 시장에서 여전히 인기가 있었기 때문입니다. 2019년에 Google Play는 네이티브 코드가 있는 앱에 64비트 라이브러리를 포함해야 한다고 규정했습니다. 그 결과, 현재 Google Play에서 네이티브 코드가 있는 앱의 99% 이상이 64비트 기기를 지원합니다. 중국 최고의 앱 스토어가 32비트 앱 배포를 중단하면 OEM은 마침내 64비트 Android 전용 빌드를 출시하기 시작합니다. 64 비트 전용 Android로 이동하면 더 나은 보안, 더 나은 성능 및 더 쉬운 유지 보수가 이점이 있습니다.

64비트 전용 Android의 채택 속도를 높이기 위해 Google은 호환성 테스트 스위트(CTS)에 "32비트 실행 파일을 실행할 수 없는 armv9 코어가 [sic] 32비트 abis를 내보내지 않는지 확인하는 새로운 테스트를 추가할 수 있습니다." 보다 구체적으로, 이 테스트는 각 CPU의 하드웨어 기능을 확인합니다. CPU가 SVE2 및 BTI를 지원한다면 Armv9 코어임을 의미합니다. Armv9 코어인 경우 32비트 ABI를 내보내서는 안 됩니다.

이 테스트는 Android 14 이상에서 시작하는 장치에서만 실행되도록 설계되었지만 이를 구현하는 패치는 아직 커밋되지 않았습니다. 즉, Armv9 CPU가있는 Android 14 출시 장치가 실제로 32 비트 앱 지원 없이 출시되어야하는지 여부는 확실하지 않습니다. 대부분의 Armv9 CPU 설계는 Cortex-A710 및 수정된 Cortex-A510을 제외하고 이미 32비트 앱 실행을 지원하지 않습니다. 이 CPU를 사용하는 Android 14 출시 장치가 64 비트 전용 Android 빌드와 함께 제공되어야하는지 여부는 명확하지 않습니다.이 테스트는 다른 Armv9 코어를 구별하지 않기 때문입니다.

8. 안드로이드 빔의 완전한 죽음

안드로이드 10의 출시와 함께, 구글은 더 이상 안드로이드 빔, 블루투스 또는 Wi-Fi 다이렉트를 통해 파일의 피어 - 투 - 피어 공유를 시작하는 기능을 사용합니다. 그러나 코드는 플랫폼 내에 남아 있었기 때문에 OEM과 땜장이가 원할 경우 쉽게 다시 추가 할 수 있습니다. 그러나 Google은 NFC 프레임 워크에서 Android Beam의 모든 흔적을 삭제하기 시작했으며,이 기능은 Android 14에서 실제로 죽을 것입니다.

9. StrongBox를 지원하는 장치는 내부자 공격 저항을 구현해야 합니다.

Android 키 저장소 시스템은 앱이 보안 컨테이너(키 저장소라고 함)에 암호화 키를 저장할 수 있도록 하는 API입니다. 암호화 키가 추출되어 손상되는 것을 방지하기 위해 키 구성 요소를 장치의 보안 하드웨어(예: 신뢰할 수 있는 실행 환경 또는 보안 요소)에 바인딩할 수 있습니다. 추가 보호를 위해 암호화 키는 자체 CPU 및 보안 스토리지를 갖춘 전용 보안 프로세서인 장치의 StrongBox에 바인딩할 수 있습니다.

CDD는 StrongBox 자격을 얻기 위해 전용 보안 프로세서가 충족해야 하는 전체 요구 사항을 간략하게 설명합니다. 이러한 요구 사항을 준수하는지 확인하기 위해 CDD는 장치가 사용자 데이터의 암호화 키를 보호하기 위해 IAR(내부자 공격 저항)을 구현할 것을 권장합니다. IAR은 내부자가 "펌웨어 서명 키에 액세스하면 StrongBox가 비밀을 유출하거나 기능 보안 요구 사항을 우회하거나 중요한 사용자 데이터에 액세스 할 수있는 펌웨어를 생성 할 수 없습니다." 안드로이드 13 CDD는 IAR을 제공하기 위해 장치 구현이 "강력히 권장"된다고 말하지만 IAR은 "안드로이드 14에서 필수 요구 사항이 될 것"이라고 말합니다.

10. 업데이트 가능한 SELinux 정책

Android 13은 APEX 모듈을 통해 업데이트 가능한 SELinux 정책(SEPolicy)에 대한 지원을 도입했습니다. 최근 코드 변경에 따르면 업데이트 가능한 SEPolicy 모듈은 Android 14에서 필수가 될 것입니다. 시스템 파티션에 어떤 패키지가 포함되는지 정의하는 AOSP의 메이크 파일이 SEPolicy APEX의 패키지 이름 인 'com.android.sepolicy'를 포함하도록 업데이트되었습니다. 구글이 이 APEX를 기본적으로 포함시키기를 원하는 이유는 그들이 "기존 플랫폼 정책의 일부를 정점 sepolicy로 옮길 계획"이기 때문이다.

11. AOSP의 장치 간 API

Google I/O 2022에서 Google은 Bluetooth 저에너지(BLE), 초광대역(UWB) 및 WiFi를 통해 근처의 장치 검색, 장치 웨이크업, 보안 통신 및 다중 장치 세션을 간소화하는 API 집합인 교차 장치 SDK를 발표했습니다. SDK용 개발자 프리뷰는 8월 말에 출시되었으며 새로운 Google Play 서비스 라이브러리를 통해 Android 8.0+ 기기에서 사용할 수 있습니다.

12. 앱이 정확한 알람 API를 사용하기 전에 사용자에게 요청해야 할 수 있습니다.

앱은 AlarmManager의 정확한 알람 API를 사용하여 특정 시간에 실행되도록 백그라운드 작업을 예약할 수 있습니다. Android 12 이전에는 앱이 이러한 API를 사용하기 위해 권한을 보유 할 필요가 없었습니다. 그러나 Android 12부터는 API 레벨 31 이상을 대상으로 하는 앱이 정확한 알람 API를 사용하기 위해 SCHEDULE_EXACT_ALARM 권한을 보유해야 했습니다. 이 권한은 앱을 설치할 때 자동으로 부여되지만 설정의 "알람 및 미리 알림" 메뉴를 통해 사용자가 취소할 수 있습니다.

알람 앱, 시계 앱 또는 일정 앱과 같이 정확한 알람을 예약하는 데 의존하는 앱은 사용자가 이 권한을 취소하면 안정적으로 작동하지 않습니다. 이러한 일이 발생하지 않도록 하려면 앱이 정확한 알람 API를 사용하기 전에 이 권한을 보유하고 있는지 확인하는 것이 좋습니다. 그럼에도 불구하고 일부 사용자는 권한을 다시 부여하도록 요청 받았을 때에도 권한을 다시 부여하지 않기로 선택할 수 있으므로 핵심 기능에 의존하는 앱은 문제가 발생할 수 있습니다.

핵심 기능을 위해 정확한 알람 API를 사용하는 앱의 경우 Android 13에는 앱을 설치한 후 사용자가 이전을 취소할 수 없다는 점을 제외하면 USE_EXACT_ALARM와 유사하게 작동하는 SCHEDULE_EXACT_ALARM이라는 새로운 권한이 도입되었습니다. 이를 통해 이러한 앱은 사용자 프롬프트없이 정확한 알람을 예약 할 수 있습니다. 사용자가 USE_EXACT_ALARM 권한을 취소할 수 없으므로 Google Play는 이 권한의 사용을 감사하여 알람 앱, 시계 앱 및 캘린더 앱만 요청할 수 있도록 합니다.

SCHEDULE_EXACT_ALARM 권한은 정확한 경보 API를 사용해야 하지만 핵심 기능에 의존하지 않는 앱에 대한 옵션으로 남아 있습니다. Google은 API 레벨 33을 대상으로 하는 앱에 대한 SCHEDULE_EXACT_ALARM 권한을 시스템이 자동으로 거부하도록 할 계획이었으며, 이는 사용자가 설정에서 명시적으로 권한을 부여해야 함을 의미합니다. 그러나 Google은이 변경 사항의 적용을 연기했기 때문에 Android 13에 대한 권한을 요청하는 앱은 대상 SDK 버전에 관계없이 자동으로 부여됩니다.

SCHEDULE_EXACT_ALARM의 기본 동작이 Android 14에서 변경될지 확실하지 않지만 주석은 "다음 SDK에서"적용될 수 있다고 제안합니다. 이 변경의 이점은 더 적은 수의 앱이 정확한 경보 API를 요청하고 액세스 권한을 부여받는다는 것입니다. 앱이 특정 시간에 작업을 수행하도록 절대적으로 예약해야 하는 경우가 아니라면 Android 일괄 처리 및 대기열 작업이 장치가 유휴 상태이거나 충전 중일 때와 같이 최적의 시간에 실행되도록 하는 것이 좋습니다.