2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
비 A/B 시스템 업데이트
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
비 A/B 업데이트는 이전 Android 기기 (Android 6 이하)에서 사용되는 지원 중단된 OTA 방법입니다. 이러한 기기에는 다운로드한 업데이트 패키지를 압축 해제하고 업데이트를 다른 파티션에 적용하는 데 필요한 소프트웨어가 포함된 전용 복구 파티션이 있습니다.
A/B 파티션이 없는 이전 Android 기기의 경우 일반적으로 플래시 공간에 다음 파티션이 포함됩니다.
- 부팅
- Linux 커널과 (RAM 디스크에 로드되는) 최소 루트 파일 시스템을 포함합니다. 시스템 파티션과 다른 파티션을 마운트하고 시스템 파티션에 있는 런타임을 시작합니다.
- 시스템
- AOSP (Android 오픈소스 프로젝트)에서 소스 코드를 사용할 수 있는 시스템 애플리케이션 및 라이브러리가 포함되어 있습니다. 일반 작업 중 이 파티션은 읽기 전용으로 마운트됩니다. 이 파티션의 콘텐츠는 OTA 업데이트 중에만 변경됩니다.
- 공급업체
- AOSP (Android 오픈소스 프로젝트)에서 소스 코드를 사용할 수 없는 시스템 애플리케이션 및 라이브러리가 포함되어 있습니다. 일반 작업 중 이 파티션은 읽기 전용으로 마운트됩니다. 이 파티션의 콘텐츠는 OTA 업데이트 중에만 변경됩니다.
- 사용자 데이터
- 사용자 등이 설치한 애플리케이션에서 저장한 데이터를 저장합니다. 이 파티션은 일반적으로 OTA 업데이트 프로세스에 의해 변경되지 않습니다.
- 캐시
- 일부 애플리케이션에서 사용하고 다운로드된 OTA 업데이트 패키지의 저장에 사용되는 임시 보관 영역 (이 파티션에 액세스하려면 특수 앱 권한이 필요함)입니다. 다른 프로그램에서는 파일이 언제든지 사라질 수 있다는 점을 예상하고 이 공간을 사용합니다. 일부 OTA 패키지를 설치하면 이 파티션이 완전히 삭제될 수 있습니다. 캐시에는 OTA 업데이트의 업데이트 로그도 들어 있습니다.
- 복구
- 패키지를 읽고 그 콘텐츠를 사용하여 다른 파티션을 업데이트하는 특수 복구 바이너리와 커널을 포함하고 있는 2차 전체 Linux 시스템을 포함하고 있습니다.
- 기타
-
OTA 패키지가 적용되는 동안 기기가 다시 시작될 때 수행한 작업에 대해 일부 정보를 숨기기 위해 복구에서 사용하는 작은 파티션입니다.
OTA 업데이트의 수명
일반적인 OTA 업데이트에는 다음 단계가 포함됩니다.
-
기기는 OTA 서버를 통해 정기적으로 체크인하고 업데이트 패키지의 URL 및 사용자에게 표시할 설명 문자열을 포함하여 업데이트 사용 가능 여부를 알립니다.
-
다운로드를 캐시 또는 데이터 파티션으로 업데이트하고 암호화 서명을
/system/etc/security/otacerts.zip의 인증서와 비교하여 확인합니다. 사용자에게 업데이트를 설치하라는 메시지가 표시됩니다.
-
부팅 파티션의 커널 대신 복구 파티션의 커널과 시스템이 부팅되는 복구 모드로 기기가 재부팅됩니다.
-
복구 바이너리는 init로 시작됩니다. 다운로드한 패키지를 가리키는 명령줄 인수를
/cache/recovery/command에서 찾습니다.
-
복구는 복구 파티션에 포함된 RAM 디스크의 일부인
/res/keys의 공개 키를 기준으로 패키지의 암호화 서명을 확인합니다.
-
데이터는 패키지에서 가져와 필요에 따라 부팅, 시스템 또는 공급업체 파티션을 업데이트하는 데 사용됩니다. 시스템 파티션에 남아 있는 새 파일 중 하나에는 새 복구 파티션의 콘텐츠가 포함되어 있습니다.
-
기기를 정상적으로 재부팅합니다.
-
새로 업데이트된 부팅 파티션이 로드되어 마운트되고 새로 업데이트된 시스템 파티션의 바이너리 실행을 시작합니다.
-
정상 시작 시 시스템은 복구 파티션의 콘텐츠를 원하는 콘텐츠 (이전에
/system에 파일로 저장한 콘텐츠)와 비교하여 확인합니다. 콘텐츠가 다르므로 복구 파티션은 원하는 콘텐츠로 다시 플래시됩니다. 후속 부팅 시에는 복구 파티션에 이미 새 콘텐츠가 포함되어 있으므로 다시 플래시할 필요가 없습니다.
시스템 업데이트가 완료되었습니다! 업데이트 로그는 /cache/recovery/last_log.#에서 확인할 수 있습니다.
업데이트 패키지
업데이트 패키지는 실행 바이너리 META-INF/com/google/android/update-binary가 포함된 .zip 파일입니다. 패키지의 서명을 확인한 후 recovery는 이 바이너리를 /tmp로 추출하고 바이너리를 실행하여 다음 인수를 전달합니다.
-
업데이트 바이너리 API 버전 번호. 인수가 업데이트 바이너리 변경사항에 전달되면 이 번호가 증분됩니다.
-
명령어 파이프의 파일 설명자. 업데이트 프로그램은 이 파이프를 사용하여 명령어를 다시 복구 바이너리로 전송할 수 있습니다(대부분 진행 상황을 사용자에게 표시하는 등의 UI 변경사항에 사용됨).
-
업데이트 패키지
.zip 파일의 파일 이름.
업데이트 패키지는 정적으로 연결된 모든 바이너리를 업데이트 바이너리로 사용할 수 있습니다. OTA 패키지 구성 도구는 여러 설치 작업을 할 수 있는 간단한 스크립트 언어를 제공하는 업데이터 프로그램 (bootable/recovery/updater)을 사용합니다. 기기에서 실행되는 다른 모든 바이너리는 대체 가능합니다.
업데이터 바이너리, edify 문법 및 기본 함수에 관한 자세한 내용은 OTA 패키지 내부를 참고하세요.
이전 출시에서 이전
Android 2.3/3.0/4.0 버전에서 이전할 때 주요 변경사항은 미리 정의된 이름이 있는 C 함수 세트에서 모든 기기별 기능을 C++ 객체로 변환하는 것입니다.
다음 표에는 거의 동일한 목적을 실행하는 이전 함수와 새 메서드가 나와 있습니다.
| C 함수 |
C ++ 메서드 |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
이전 함수를 새 메서드로 변환하는 것은 상당히 간단해야 합니다. 새 make_device() 함수를 추가하여 새 기기 서브클래스의 인스턴스를 만들고 반환해야 합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Non-A/B system updates\n\nNon AB updates are a deprecated OTA methodology used by older Android Devices (Android 6 and\nearlier). These devices have a dedicated recovery partition containing the software needed to\nunpack a downloaded update package and apply the update to the other partitions.\n\n\nOn older Android devices without A/B partitions, the flash space typically contains the\nfollowing partitions:\n\nboot\n:\n Contains the Linux kernel and a minimal root filesystem (loaded into a RAM disk). It mounts\n system and other partitions and starts the runtime located on the system partition.\n\nsystem\n:\n Contains system applications and libraries that have source code available on Android Open\n Source Project (AOSP). During normal operation, this partition is mounted read-only; its\n contents change only during an OTA update.\n\nvendor\n:\n Contains system applications and libraries that do *not* have source code available\n on Android Open Source Project (AOSP). During normal operation, this partition is mounted\n read-only; its contents change only during an OTA update.\n\nuserdata\n:\n Stores the data saved by applications installed by the user, etc. This partition is not\n normally touched by the OTA update process.\n\ncache\n:\n Temporary holding area used by a few applications (accessing this partition requires special\n app permissions) and for storage of downloaded OTA update packages. Other programs use this\n space with the expectation that files can disappear at any time. Some OTA package\n installations may result in this partition being wiped completely. The cache also contains\n the update logs from an OTA update.\n\nrecovery\n:\n Contains a second complete Linux system, including a kernel and the special recovery binary\n that reads a package and uses its contents to update the other partitions.\n\nmisc\n:\n Tiny partition used by recovery to stash some information away about what it is doing in\n case the device is restarted while the OTA package is being applied.\n\nLife of an OTA update\n---------------------\n\nA typical OTA update contains the following steps:\n\n1. Device performs regular check in with OTA servers and is notified of the availability of an update, including the URL of the update package and a description string to show the user.\n2. Update downloads to a cache or data partition, and its cryptographic signature is verified against the certificates in `/system/etc/security/otacerts.zip`. User is prompted to install the update.\n3. Device reboots into recovery mode, in which the kernel and system in the recovery partition are booted instead of the kernel in the boot partition.\n4. Recovery binary is started by init. It finds command-line arguments in `/cache/recovery/command` that point it to the downloaded package.\n5. Recovery verifies the cryptographic signature of the package against the public keys in `/res/keys` (part of the RAM disk contained in the recovery partition).\n6. Data is pulled from the package and used to update the boot, system, and/or vendor partitions as necessary. One of the new files left on the system partition contains the contents of the new recovery partition.\n7. Device reboots normally.\n 1. The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.\n 2. As part of normal startup, the system checks the contents of the recovery partition against the desired contents (which were previously stored as a file in `/system`). They are different, so the recovery partition is reflashed with the desired contents. (On subsequent boots, the recovery partition already contains the new contents, so no reflash is necessary.)\n\n\nThe system update is complete! The update logs can be found in\n`/cache/recovery/last_log.`\u003cvar translate=\"no\"\u003e#\u003c/var\u003e.\n\nUpdate packages\n---------------\n\n\nAn update package is a `.zip` file that contains the executable binary\n`META-INF/com/google/android/update-binary`. After verifying the signature on the\npackage, `recovery` extracts this binary to `/tmp` and runs the binary,\npassing the following arguments:\n\n- **Update binary API version number**. If the arguments passed to the update binary change, this number increments.\n- **File descriptor of the *command pipe***. The update program can use this pipe to send commands back to the recovery binary, mostly for UI changes, such as indicating progress to the user.\n- **Filename of the update package `.zip` file**.\n\n\nAn update package can use any statically linked binary as the update binary. The OTA package\nconstruction tools use the updater program (`bootable/recovery/updater`), which\nprovides a simple scripting language that can do many installation tasks. You can substitute\nany other binary running on the device.\n\n\nFor details on the updater binary, edify syntax, and builtin functions, see\n[Inside OTA Packages](/docs/core/ota/nonab/inside_packages).\n\nMigrate from previous releases\n------------------------------\n\n\nWhen migrating from Android 2.3/3.0/4.0 release, the major change is the conversion of all the\ndevice-specific functionality from a set of C functions with predefined names to C++ objects.\nThe following table lists the old functions and the new methods that serve a roughly\nequivalent purpose:\n\n| C function | C++ method |\n|---------------------------------------------|----------------------------------------------------------|\n| device_recovery_start() | Device::RecoveryStart() |\n| device_toggle_display() device_reboot_now() | RecoveryUI::CheckKey() (also RecoveryUI::IsKeyPressed()) |\n| device_handle_key() | Device::HandleMenuKey() |\n| device_perform_action() | Device::InvokeMenuItem() |\n| device_wipe_data() | Device::WipeData() |\n| device_ui_init() | ScreenRecoveryUI::Init() |\n\n\nConversion of old functions to new methods should be reasonably straightforward. Don't forget\nto add the new `make_device()`\nfunction to create and return an instance of your new Device subclass."]]
