Android 10에서는 APK 기반 시간대 데이터 업데이트 메커니즘(Android 8.1 및 Android 9에서 사용 가능)을 지원 중단하고 APEX 기반 모듈 업데이트 메커니즘으로 대체합니다. AOSP 8.1~13에는 OEM이 APK 기반 업데이트를 사용 설정하는 데 필요한 플랫폼 코드가 계속 포함되므로 Android 10으로 업그레이드하는 기기는 파트너가 제공한 시간대 데이터 업데이트를 APK를 통해 계속 받을 수 있습니다. 그러나 APK 기반 업데이트가 APEX 기반 업데이트를 대체하기 때문에(즉, APK 업데이트를 받는 기기가 APEX 기반 업데이트를 무시하므로) 모듈 업데이트도 받고 있는 프로덕션 기기에 APK 업데이트 메커니즘을 사용하면 안 됩니다.
시간대 업데이트(Android 10 이상)
Android 10 이상에서 지원되는 시간대 데이터 모듈은 일광 절약 시간(DST)과 Android 기기의 시간대를 업데이트하여 종교적, 정치적, 지정학적 이유로 자주 변경될 수 있는 데이터를 표준화합니다.
업데이트에는 다음과 같은 프로세스가 사용됩니다.
- 하나 이상의 정부가 자국의 시간대 규칙을 변경하면 IANA가 이에 대응하여 시간대 데이터베이스에 업데이트를 출시합니다.
- Google 또는 Android 파트너가 업데이트된 시간대를 포함하는 시간대 데이터 모듈 업데이트(APEX 파일)를 준비합니다.
- 최종 사용자 기기에서 업데이트를 다운로드하고 재부팅한 후 변경사항을 적용합니다. 적용된 이후에 기기의 시간대 데이터에 업데이트의 새로운 시간대 데이터가 포함됩니다.
모듈에 관한 자세한 내용은 모듈식 시스템 구성요소를 참조하세요.
시간대 업데이트(Android 8.1~9)
참고: APK 기반 시간대 데이터 업데이트 메커니즘 기능이 Android U부터 완전히 삭제되었으므로 소스 코드에서 찾을 수 없습니다. 파트너는 시간대 메인라인 모듈로 완전히 이전해야 합니다.
Android 8.1 및 Android 9에서는 OEM이 시스템 업데이트를 요구하지 않고도 APK 기반 메커니즘을 사용하여 업데이트된 시간대 규칙 데이터를 기기에 푸시할 수 있습니다. 이 메커니즘은 사용자가 제시간에 업데이트를 수신하여 Android 기기의 유용한 전체 기간을 연장하고 Android 파트너가 시스템 이미지 업데이트와 별개로 시간대 업데이트를 테스트할 수 있게 해줍니다.
Android 핵심 라이브러리팀은 스톡 Android 기기의 시간대 규칙을 업데이트하는 데 필요한 데이터 파일을 제공합니다. OEM은 기기의 시간대 업데이트를 생성할 때 이러한 데이터 파일을 사용할 수 있으며, 원하는 경우에는 자체 데이터 파일을 생성할 수도 있습니다. 어떠한 경우든 OEM은 지원되는 기기의 시간대 규칙 업데이트와 관련된 QA/테스트, 시기 및 출시에 대한 제어 권한을 보유합니다.
Android 시간대 소스 코드 및 데이터
모든 스톡 Android 기기(이 기능을 사용하지 않는 기기 포함)는 시간대 규칙 데이터가 필요하며, /system 파티션의 기본적인 시간대 규칙 데이터 세트와 함께 제공되어야 합니다. 그러면 이 데이터는 Android 소스 트리의 다음 라이브러리에 있는 코드에 의해 사용됩니다.
libcore/의 관리 코드(예:java.util.TimeZone)는tzdata및tzlookup.xml파일을 사용합니다.bionic/의 네이티브 라이브러리 코드(예:mktime이면 localtime 시스템 호출)는tzdata파일을 사용합니다.external/icu/의 ICU4J/ICU4C 라이브러리 코드는 icu.dat파일을 사용합니다.
이러한 라이브러리는 /data/misc/zoneinfo/current 디렉터리에 있을 수 있는 오버레이 파일을 추적합니다. 오버레이 파일에는 /system을 변경하지 않고도 기기가 업데이트될 수 있도록 개선된 시간대 규칙 데이터가 포함되어야 합니다.
시간대 규칙 데이터가 필요한 Android 시스템 구성요소는 먼저 다음 위치를 확인합니다.
libcore/및bionic/코드는tzdata및tzlookup.xml파일의/data사본을 사용합니다.- ICU4J/ICU4C 코드는
/data의 파일을 사용하며, 존재하지 않는 데이터(형식, 현지화된 문자열 등)가 있으면/system파일로 돌아갑니다.
distro 파일
distro .zip 파일에는 /data/misc/zoneinfo/current 디렉터리를 채우는 데 필요한 데이터 파일이 포함됩니다. 또한 distro 파일에는 기기가 버전 관리 문제를 감지할 수 있게 해주는 메타데이터도 포함됩니다.
distro 파일 형식은 Android 출시에 종속됩니다. 이는 ICU 버전, Android 플랫폼 요구사항 및 기타 출시 변경사항에 따라 콘텐츠가 변경되기 때문입니다. Android는 IANA 업데이트가 있을 때마다 지원되는 Android 출시의 distro 파일을 제공하고 플랫폼 시스템 파일을 업데이트합니다. 기기를 최신 상태로 유지하기 위해 OEM은 이러한 distro 파일을 사용하거나, distro 파일을 생성하는 데 필요한 스크립트와 기타 파일이 포함된 Android 소스 트리를 사용하여 자체 파일을 생성할 수 있습니다.
시간대 업데이트 구성요소
시간대 규칙을 업데이트하려면 distro 파일을 기기에 전송하고 그 안에 포함된 파일을 안전하게 설치해야 합니다. 전송 및 설치 시 다음이 필요합니다.
- 플랫폼 서비스 기능(
timezone.RulesManagerService) - 기본적으로 사용 중지되어 있습니다. OEM은 구성을 통해 기능을 사용 설정해야 합니다.RulesManagerService는 시스템 서버 프로세스에서 실행되며,/data/misc/zoneinfo/staged에 기록함으로써 시간대 업데이트 작업을 준비합니다. 또한RulesManagerService는 이미 준비된 작업을 교체하거나 삭제할 수도 있습니다. -
TimeZoneUpdater- 업데이트할 수 없는 시스템 앱입니다(업데이터 앱이라고도 함). OEM은 기능을 사용하여 기기의 시스템 이미지에 이 앱을 포함해야 합니다. - OEM
TimeZoneData- distro 파일을 기기로 전송하여 업데이터 앱에 제공하는 업데이트 가능한 시스템 앱입니다(데이터 앱이라고도 함). OEM은 기능을 사용하여 기기의 시스템 이미지에 이 앱을 포함해야 합니다. tzdatacheck- 시간대 업데이트를 정확하고 안전하게 작업하는 데 필요한 부팅 시간 바이너리입니다.
Android 소스 트리에는 위의 구성요소와 관련된 일반 소스 코드가 포함됩니다. OEM은 이러한 코드를 선택하여 수정 없이 사용할 수 있습니다. OEM이 기능을 올바르게 사용 설정했는지 자동으로 확인할 수 있도록 테스트 코드가 제공됩니다.
distro 설치
distro 설치 프로세스에는 다음과 같은 단계가 포함됩니다.
- 앱 스토어 다운로드 또는 사이드로드를 통해 데이터 앱이 업데이트됩니다.
timezone.RulesManagerServer/timezone.PackageTracker클래스를 통해 시스템 서버 프로세스는 구성된 OEM별 데이터 앱 패키지 이름의 변경사항을 모니터링합니다.
그림 1. 데이터 앱 업데이트 - 시스템 서버 프로세스에서 업데이트 검사를 트리거합니다. 프로세스는 이를 위해 고유한 일회성 토큰을 사용하여 타겟팅된 인텐트를 업데이터 앱으로 브로드캐스트합니다. 시스템 서버는 가장 최근에 트리거한 검사가 언제 완료되었는지 파악할 수 있도록 가장 최근에 생성된 토큰을 추적합니다. 다른 토큰은 전부 무시됩니다.
그림 2. 업데이트 검색 트리거 - 업데이트 검사가 진행되는 동안 업데이터 앱에서 다음 작업을 실행합니다.
- RulesManagerService를 호출하여 현재의 기기 상태를 쿼리합니다.
그림 3. 데이터 앱 업데이트, RulesManagerService 호출 - 잘 정의된 ContentProvider URL 및 열 사양을 쿼리하여 distro에 관한 정보를 가져옴으로써 데이터 앱을 쿼리합니다.
그림 4. 데이터 앱 업데이트, distro에 관한 정보 가져오기
- RulesManagerService를 호출하여 현재의 기기 상태를 쿼리합니다.
- 보유한 정보를 기반으로 업데이터 앱이 적절한 조치를 취합니다. 사용 가능한 조치에는 다음이 포함됩니다.
- 설치를 요청합니다. 데이터 앱에서 distro 데이터가 판독되어 시스템 서버의 RulesManagerService로 전달됩니다. RulesManagerService가 distro 형식 버전 및 콘텐츠가 기기에 관해 적절한지 다시 확인하고 설치를 준비합니다.
- 설치 제거를 요청합니다(드문 경우).
/data의 업데이트된 APK가 사용 중지 또는 설치 제거되며 기기가/system에 존재하는 버전으로 돌아가는 상황을 예로 들 수 있습니다. - 아무 조치도 취하지 않습니다. 데이터 앱 distro가 잘못되었다고 확인될 때 발생합니다.
그림 5. 검사 완료 - 재부팅 및 tzdatacheck를 실행합니다. 다음에 기기가 재부팅되면 tzdatacheck 바이너리가 모든 준비된 작업을 실행합니다. tzdatacheck 바이너리는 다음 작업을 실행할 수 있습니다.
- 다른 시스템 구성요소가 열리고 파일 사용을 시작하기 전에
/data/misc/zoneinfo/current파일의 생성, 교체 또는 삭제를 처리하여 준비된 작업을 실행합니다. /data의 파일이 최신 플랫폼 버전에 적합한지 확인합니다. 기기가 조금 전에 시스템 업데이트를 받았고 distro 형식 버전이 변경되었다면 적합하지 않을 수 있습니다.- IANA 규칙 버전이
/system의 버전과 같거나 그 이후 버전인지 확인합니다. 이렇게 하면 시스템 업데이트로 인해 기기가/system이미지에 표시된 것보다 이전의 시간대 규칙 데이터를 유지하는 것을 방지할 수 있습니다.
- 다른 시스템 구성요소가 열리고 파일 사용을 시작하기 전에
안정성
엔드 투 엔드 설치 프로세스는 비동기로 진행되며, 3가지 OS 프로세스에 걸쳐 분할됩니다. 설치가 진행되는 동안 기기는 전력을 잃거나 디스크 공간이 부족하거나 다른 문제를 접할 수 있으며, 이로 인해 설치 검사가 완료되지 않을 수 있습니다. 최상의 실패 사례에서는 업데이터 앱이 시스템 서버에 실패를 알립니다. 최악의 실패 사례에서는 RulesManagerService가 아예 호출을 수신하지 않습니다.
이를 처리하기 위해 시스템 서버는 트리거된 업데이트 검사가 완료되었는지 여부 및 마지막으로 검사한 데이터 앱의 버전 코드를 추적합니다. 기기가 유휴 상태이고 충전 중일 때 시스템 서버 코드는 현재 상태를 확인할 수 있습니다. 완료되지 않은 업데이트 검사나 예상치 못한 데이터 앱 버전을 감지하면 자발적으로 업데이트 검사를 트리거합니다.
보안
사용 설정되면 시스템 서버의 RulesManagerService 코드가 여러 검사를 실행하여 시스템을 사용해도 안전한지 확인합니다.
- 시스템 이미지가 잘못 구성되었음을 시사하는 문제가 있으면 기기가 재부팅되지 않습니다. 업데이터 또는 데이터 앱 구성이 잘못되었거나
/system/priv-app에 업데이터 또는 데이터 앱이 없는 상황을 예로 들 수 있습니다. - 잘못된 데이터 앱이 설치되었음을 시사하는 문제가 있으면 기기가 재부팅되지만 업데이트 검사는 트리거되지 않습니다. 필수 시스템 권한이 부족하거나 데이터 앱이 예상 URI에 ContentProvider를 노출하지 않는 상황을 예로 들 수 있습니다.
/data/misc/zoneinfo 디렉터리의 파일 권한은 SELinux 규칙을 사용하여 적용됩니다. 모든 APK와 마찬가지로 데이터 앱은 /system/priv-app 버전을 서명하는 데 사용된 동일한 키로 서명되어야 합니다. 데이터 앱은 전용 OEM별 패키지 이름 및 키를 보유해야 합니다.
시간대 업데이트 통합
일반적으로 OEM은 시간대 업데이트 기능을 사용 설정하기 위해 다음을 수행합니다.
- 자체 데이터 앱을 구축합니다.
- 시스템 이미지 빌드에 업데이터 및 데이터 앱을 포함합니다.
- RulesManagerService를 사용 설정하도록 시스템 서버를 구성합니다.
준비 중
시작 전에 OEM은 다음과 같은 정책, QA 및 보안 고려사항을 검토해야 합니다.
- 데이터 앱의 전용 앱별 서명 키를 생성합니다.
- 시간대 업데이트의 릴리스 및 버전 관리 전략을 수립하여 어떤 기기를 업데이트할지, 어떻게 해야 업데이트가 업데이트를 필요로 하는 기기에만 설치되도록 할지를 이해합니다. 예를 들어 OEM은 모든 기기에 대해 단일 데이터 앱을 보유하는 것이 좋으며, 원하는 경우 여러 기기에 서로 다른 데이터 앱을 보유할 수도 있습니다. 이러한 결정은 패키지 이름에 선택에 영향을 미치며, 사용되는 버전 코드와 QA 전략에도 영향을 미칠 수 있습니다.
- AOSP의 스톡 Android 시간대 데이터를 사용해야 할지, 아니면 자체 데이터를 생성해야 할지를 이해합니다.
데이터 앱 생성
AOSP에는 packages/apps/TimeZoneData에 데이터 앱을 생성하는 데 필요한 모든 소스 코드 및 빌드 규칙이 포함되어 있으며 AndroidManifest.xml 파일 및 packages/apps/TimeZoneData/oem_template에 있는 기타 파일과 관련된 지침과 템플릿 예시도 함께 포함되어 있습니다. 템플릿 예시에는 실제 데이터 앱 APK의 빌드 타겟과 데이터 앱의 테스트 버전 생성을 위한 추가 타겟이 포함됩니다.
OEM은 자체 아이콘, 이름, 번역 및 기타 세부정보로 데이터 앱을 맞춤설정할 수 있습니다. 하지만 데이터 앱을 실행할 수 없으므로 아이콘이 설정 > 앱 화면에만 표시됩니다.
데이터 앱은 최초 출시를 위한 시스템 이미지에 추가하면 좋은 APK를 생성하는 타파스 빌드로 빌드되도록 되어 있으며, 후속 업데이트에는 앱 스토어를 통해 서명 및 배포되어야 합니다. 타파스 사용에 관한 자세한 내용은 타파스를 이용한 데이터 앱 빌드를 참조하세요.
OEM은 /system/priv-app의 기기 시스템 이미지에 사전 빌드된 데이터 앱을 설치해야 합니다. 타파스 빌드 프로세스에 의해 생성된 사전 빌드 APK를 시스템 이미지에 포함하기 위해 OEM은 packages/apps/TimeZoneData/oem_template/data_app_prebuilt의 예시 파일을 복사할 수 있습니다. 예시 템플릿에는 테스트 도구 모음의 데이터 앱 테스트 버전을 포함하기 위한 빌드 타겟도 포함됩니다.
시스템 이미지에 업데이터 및 데이터 앱 포함
OEM은 업데이터 및 데이터 앱 APK를 시스템 이미지의 /system/priv-app 디렉터리에 배치해야 합니다. 이렇게 하려면 시스템 이미지 빌드에 업데이터 앱 및 데이터 앱 사전 빌드 타겟이 명시적으로 포함되어야 합니다.
업데이터 앱은 플랫폼 키로 서명되어야 하며 다른 모든 시스템 앱처럼 포함되어야 합니다. 타겟은 packages/apps/TimeZoneUpdater에서 TimeZoneUpdater로 정의됩니다. 데이터 앱 포함은 OEM과 관련이 있으며, 사전 빌드에서 선택한 타겟 이름에 종속됩니다.
시스템 서버 구성
시간대 업데이트를 사용 설정하려는 OEM은 frameworks/base/core/res/res/values/config.xml에 정의된 구성 속성을 재정의하여 시스템 서버를 구성할 수 있습니다.
| 속성 | 설명 | 재정의 필요 여부 |
|---|---|---|
config_enableUpdateableTimeZoneRules |
RulesManagerService를 사용 설정하려면 true로 설정해야 합니다. |
예 |
config_timeZoneRulesUpdateTrackingEnabled |
시스템이 데이터 앱 변경사항을 수신 대기하도록 하려면 true로 설정해야 합니다. |
예 |
config_timeZoneRulesDataPackage |
OEM별 데이터 앱의 패키지 이름입니다. | 예 |
config_timeZoneRulesUpdaterPackage |
기본 업데이터 앱을 위해 구성됩니다. 다른 업데이터 앱 구현을 제공할 때에만 변경됩니다. | 아니요 |
config_timeZoneRulesCheckTimeMillisAllowed |
RulesManagerService에 의해 트리거되는 업데이트 검사와 설치, 설치 제거 또는 동작 없음 응답 간에 허용되는 시간입니다. 이 시점 이후에는 자체적인 안정성 트리거가 발생할 수 있습니다. | 아니요 |
config_timeZoneRulesCheckRetryCount |
RulesManagerService가 추가 생성을 중단하기 전에 허용되는 순차적 업데이트 실패 검사 횟수입니다. | 아니요 |
구성 재정의는 공급업체 등이 아닌 시스템 이미지에 있어야 합니다. 이는 잘못 구성된 기기가 부팅을 거부할 수 있기 때문입니다. 구성 재정의가 공급업체 이미지에 있었던 경우에는 데이터 앱(또는 다른 데이터 앱/업데이터 앱 패키지 이름) 없이 시스템 이미지를 업데이트할 경우 구성 오류로 간주됩니다.
xTS 테스트
xTS란 CTS 및 VTS 등의 Tradefed를 사용하는 표준 Android 테스트 도구 모음과 유사한 모든 OEM 관련 테스트 도구 모음을 의미합니다. 이러한 테스트 도구 모음을 보유한 OEM은 제공받은 Android 시간대 업데이트 테스트를 다음 위치에 추가할 수 있습니다.
packages/apps/TimeZoneData/testing/xts에는 기본 자동화 기능 테스트에 필요한 코드가 포함됩니다.packages/apps/TimeZoneData/oem_template/xts에는 Tradefed와 유사한 xTS 도구 모음에 테스트를 포함하기 위한 샘플 디렉터리 구조가 포함됩니다. 다른 템플릿 디렉터리와 마찬가지로 OEM은 필요에 따라 복사하고 맞춤설정해야 합니다.packages/apps/TimeZoneData/oem_template/data_app_prebuilt에는 테스트에서 요구하는 사전 빌드 테스트 APK를 포함하기 위한 빌드 시간 구성이 포함됩니다.
시간대 업데이트 생성
IANA에서 새로운 시간대 규칙 집합을 출시하면 Android 핵심 라이브러리팀은 AOSP로 업데이트 출시의 패치를 생성합니다. 스톡 Android 시스템 및 distro 파일을 사용하는 OEM은 이러한 커밋을 선택하여 데이터 앱의 새 버전을 생성하는 데 사용한 후 새 버전을 출시하여 프로덕션의 기기를 업데이트할 수 있습니다.
데이터 앱에는 Android 버전과 밀접하게 연결된 distro 파일이 포함되어 있으므로 OEM은 OEM이 업데이트하려는 지원되는 모든 Android 출시를 위해 새 버전의 데이터 앱을 생성해야 합니다. 예를 들어 Android 8.1, 9 및 10 기기의 업데이트를 제공하고 싶은 OEM은 프로세스를 3회 완료해야 합니다.
1단계: system/timezone 및 external/icu 데이터 파일 업데이트
이 단계에서 OEM은 AOSP의 release-dev 분기에서 system/timezone 및 external/icu의 스톡 Android 커밋을 가져온 후 이러한 커밋을 Android 소스 코드의 사본에 적용합니다.
system/timezone AOSP 패치에는 system/timezone/input_data 및 system/timezone/output_data의 업데이트된 파일이 포함됩니다. 추가적인 로컬 수정을 적용해야 하는 OEM은 입력 파일을 수정한 후 system/timezone/input_data 및 external/icu의 파일을 사용하여 output_data에 파일을 생성할 수 있습니다.
가장 중요한 파일은 데이터 앱 APK가 빌드될 때 자동으로 포함되는 system/timezone/output_data/distro/distro.zip입니다.
2단계: 데이터 앱의 버전 코드 업데이트
이 단계에서 OEM은 데이터 앱의 버전 코드를 업데이트합니다. 빌드는 자동으로 distro.zip을 선택하지만, 데이터 앱의 새 버전은 새 버전 코드를 보유해야만 새 버전으로 인식될 수 있으며, 미리 로드된 데이터 앱이나 이전 업데이트에 의해 기기에 설치된 데이터 앱을 교체하는 데 사용될 수 있습니다.
package/apps/TimeZoneData/oem_template/data_app에서 복사한 파일을 사용하여 데이터 앱을 빌드할 때 다음과 같이 Android.mk의 APK에 적용된 버전 코드/버전 이름을 찾을 수 있습니다.
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
유사한 항목을 testing/Android.mk에서 찾을 수도 있지만 테스트 버전 코드가 시스템 이미지 버전보다 높아야 합니다. 자세한 내용은 버전 코드 전략 체계 예시를 참조하세요. 예시 체계 또는 유사한 체계가 사용되었다면 테스트 버전 코드를 업데이트할 필요가 없습니다. 테스트 버전 코드는 실제 버전 코드보다 무조건 높기 때문입니다.
3단계: 재빌드, 서명, 테스트 및 출시
이 단계에서는 OEM이 타파스를 사용하여 APK를 재빌드하고 생성된 APK를 서명한 다음 APK를 테스트하고 릴리스합니다.
- 출시되지 않은 기기의 경우(또는 출시된 기기의 시스템 업데이트를 준비 중인 경우) 데이터 앱 사전 빌드 디렉터리에서 새 APK를 제출하여 시스템 이미지 및 xTS 테스트에 최신 APK가 있는지 확인하세요. OEM은 새 파일이 제대로 작동하는지 테스트해야 합니다(즉, CTS 및 모든 OEM 관련 자동 및 수동 테스트를 합격해야 함).
- 더 이상 시스템 업데이트를 받지 않는 출시된 기기의 경우, 서명된 APK가 앱 스토어를 통해서만 출시될 수 있습니다.
OEM은 출시 전에 기기의 데이터 앱을 QA 및 테스트해야 할 책임이 있습니다.
데이터 앱 버전 코드 전략
데이터 앱에는 기기가 올바른 APK를 수신하도록 하기 위한 적절한 버전 관리 전략이 있어야 합니다. 예를 들어 앱 스토어에서 다운로드한 버전 이전의 APK가 포함된 시스템 업데이트를 받은 경우에는 앱 스토어 버전을 유지해야 합니다.
APK 버전 코드는 다음과 같은 정보를 포함해야 합니다.
- Distro 형식 버전(주요 + 소규모)
- 증분(불투명) 버전 번호
현재의 플랫폼 API 수준은 distro 형식 버전과 밀접한 상관 관계를 지닙니다. 이는 일반적으로 각 API 수준이 ICU의 새 버전과 관련이 있기 때문입니다(따라서 distro 파일이 호환되지 않음). 향후에는 distro 파일이 여러 Android 플랫폼 버전에 걸쳐 작동할 수 있도록 Android에서 이를 변경할 수도 있으며, API 수준이 데이터 앱 버전 코드 체계에 사용되지 않습니다.
버전 코드 전략 예시
이 버전 관리 번호 체계 예시는 높은 버전의 distro 형식이 낮은 버전의 distro 형식을 대체하도록 합니다.
AndroidManifest.xml은 android:minSdkVersion을 사용하여 기존 기기가 처리할 수 없을 정도의 높은 distro 형식 버전을 포함하는 버전을 받지 않도록 합니다.
| 예 | 값 | 목적 |
|---|---|---|
| Y | 예약됨 | 향후의 대체 체계/테스트 APK를 감안합니다. 처음에는(암시적으로) 0입니다. 기본 유형이 서명된 32비트 int 유형이므로 이 체계는 최대 2개의 향후 번호 지정 체계 수정을 지원합니다. |
| 01 | 주요 형식 버전 | 3자리 10진수로 된 주요 형식 버전을 추적합니다. distro 형식은 3자리 십진수를 지원하지만 여기서는 2자리만 사용됩니다. 예상되는 API 수준당 주요 증분을 감안하면 100에 도달할 가능성이 낮습니다. 주요 버전 1은 API 수준 27과 같습니다. |
| 1 | 소규모 형식 버전 | 3자리 십진수로 된 소규모 형식 버전을 추적합니다. distro 형식은 3자리 십진수를 지원하지만 여기서는 1자리만 사용됩니다. 10에 도달할 가능성은 낮습니다. |
| X | 예약됨 | 프로덕션 릴리스의 경우 0이며, 테스트 APK의 경우 다를 수 있습니다. |
| ZZZZZ | 불투명 버전 번호 | 요청 시 할당된 10진수입니다. 필요한 경우 전면 업데이트를 허용하기 위한 간격이 포함됩니다. |
10진수 대신 바이너리를 사용하면 체계를 더욱 효율적으로 패킹할 수 있지만 이 체계는 사람이 읽을 수 있다는 이점을 지닙니다. 전체 수 범위가 소진되었다면 데이터 앱 패키지 이름이 변경될 수 있습니다.
버전 이름은 인간이 읽을 수 있는 세부정보 표현입니다(예: major=001,minor=001,iana=2017a, revision=1,respin=2).
아래 표에서 예시를 확인하세요.
| # | 버전 코드 | minSdkVersion | {Major format version},{Minor format version},{IANA rules version},{Revision} |
|---|---|---|---|
| 1 | 11000010 | O-MR1 | major=001,minor=001,iana=2017a,revision=1 |
| 2 | 21000010 | P | major=002,minor=001,iana=2017a,revision=1 |
| 3 | 11000020 | O-MR1 | major=001,minor=001,iana=2017a,revision=2 |
| 4 | 11000030 | O-MR1 | major=001,minor=001,iana=2017b,revision=1 |
| 5 | 21000020 | P | major=002,minor=001,iana=2017b,revision=1 |
| 6 | 11000040 | O-MR1 | major=001,minor=001,iana=2018a,revision=1 |
| 7 | 21000030 | P | major=002,minor=001,iana=2018a,revision=1 |
| 8 | 1123456789 | - | - |
| 9 | 11000021 | O-MR1 | major=001,minor=001,iana=2017a,revision=2,respin=2 |
- 예시 1과 2는 서로 다른 주요 형식 버전을 포함하는 동일한 2017a IANA 출시의 APK 버전 2개를 보여줍니다. 2는 1보다 높은 숫자이며, 최신 기기가 더 높은 형식 버전을 받도록 하는 데 필요합니다. minSdkVersion은 P 버전이 O 기기에 제공되지 않도록 합니다.
- 예시 3은 1의 리비전/픽스이며, 1보다 높은 숫자입니다.
- 예시 4와 5는 O-MR1 및 P의 2017b 버전을 보여줍니다. 더 높은 숫자인 만큼 각 전임자의 이전 IANA 출시/Android 리비전을 대체합니다.
- 예시 6과 7은 O-MR1 및 P의 2018a 버전을 보여줍니다.
- 예시 8은 Y를 사용하여 Y=0 체계를 완전히 교체하는 과정을 보여줍니다.
- 예시 9는 3 및 4 사이의 간격을 사용하여 apk를 리스핀하는 과정을 보여줍니다.
각 기기는 시스템 이미지의 적절히 버전 관리된 기본 APK와 함께 제공되므로 O-MR1 버전이 P 기기에 설치될 위험은 없습니다. 이 기기의 버전은 P 시스템 이미지 버전보다 숫자가 낮기 때문입니다. /data에 O-MR1 버전이 설치된 후 P에 시스템 업데이트를 받는 기기는 /data의 O-MR1 버전보다 /system 버전을 우선적으로 사용합니다. 이는 P 버전이 O-MR1용 앱보다 항상 높기 때문입니다.
타파스를 이용한 데이터 앱 빌드
OEM은 시간대 데이터 앱의 측면 대부분을 관리하고 시스템 이미지를 올바르게 구성해야 할 책임이 있습니다. 데이터 앱은 최초 출시를 위한 시스템 이미지에 추가하면 좋은 APK를 생성하는 타파스 빌드로 빌드되도록 되어 있으며, 후속 업데이트에는 앱 스토어를 통해 서명 및 배포되어야 합니다.
타파스는 축소된 소스 트리를 사용하여 배포 가능한 앱 버전을 생성하는 Android 빌드 시스템의 간소화된 버전입니다. 일반 Android 빌드 시스템이 익숙한 OEM은 빌드 파일이 일반 Android 플랫폼 빌드에서 가져온 파일인지 인지해야 합니다.
매니페스트 생성
축소된 소스 트리는 일반적으로 빌드 시스템에서 필요로 하고 앱을 빌드하는 데 필요한 Git 프로젝트만 참조하는 맞춤 매니페스트 파일로 구현됩니다. OEM은 데이터 앱 생성의 지침을 따른 후 packages/apps/TimeZoneData/oem_template 아래의 템플릿 파일을 사용하여 최소 2개의 OEM별 Git 프로젝트를 생성해야 합니다.
- 1개의 Git 프로젝트에는 앱 APK 파일(예:
vendor/oem/apps/TimeZoneData)을 생성하는 데 필요한 매니페스트 및 빌드 파일과 같은 앱 파일이 포함됩니다. 이 프로젝트에는 xTs 테스트에서 사용할 수 있는 테스트 APK의 빌드 규칙도 포함됩니다. - 다른 1개의 Git 프로젝트에는 시스템 이미지 빌드 및 xTS 테스트에 포함하기 위한 앱 빌드에 의해 생성된 서명된 APK가 포함됩니다.
앱 빌드는 플랫폼 빌드와 공유되거나 OEM과 상관없는 코드 라이브러리를 포함하는 다른 여러 Git 프로젝트를 활용합니다.
아래의 매니페스트 스니펫에는 시간대 데이터 앱의 O-MR1 빌드를 지원하는 데 필요한 Git 프로젝트의 최소 집합이 포함됩니다. OEM은 OEM별 Git 프로젝트(일반적으로 서명 인증서가 포함된 프로젝트 포함)를 이 매니페스트에 추가해야 하며, 이에 맞게 다른 분기를 구성할 수도 있습니다.
<!-- Tapas Build --> <project path="build" name="platform/build"> <copyfile src="core/root.mk" dest="Makefile" /> </project> <project path="prebuilts/build-tools" name="platform/prebuilts/build-tools" clone-depth="1" /> <project path="prebuilts/go/linux-x86" name="platform/prebuilts/go/linux-x86" clone-depth="1" /> <project path="build/blueprint" name="platform/build/blueprint" /> <project path="build/kati" name="platform/build/kati" /> <project path="build/soong" name="platform/build/soong"> <linkfile src="root.bp" dest="Android.bp" /> <linkfile src="bootstrap.bash" dest="bootstrap.bash" /> </project> <!-- SDK for system / public API stubs --> <project path="prebuilts/sdk" name="platform/prebuilts/sdk" clone-depth="1" /> <!-- App source --> <project path="system/timezone" name="platform/system/timezone" /> <project path="packages/apps/TimeZoneData" name="platform/packages/apps/TimeZoneData" /> <!-- Enable repohooks --> <project path="tools/repohooks" name="platform/tools/repohooks" revision="master" clone_depth="1" /> <repo-hooks in-project="platform/tools/repohooks" enabled-list="pre-upload" />
타파스 빌드 실행
소스 트리가 설정된 후에는 다음 명령어를 사용하여 타파스 빌드를 호출합니다.
source build/envsetup.shtapasmake -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
빌드에 성공하면 테스트용 out/dist 디렉터리에 파일이 생성됩니다. 이러한 파일은 시스템 이미지에 포함하기 위해 사전 빌드된 디렉터리에 배치하거나 앱 스토어를 통해 호환되는 기기에 배포할 수 있습니다.