27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
A/B olmayan sistem güncellemeleri
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
AB dışı güncellemeler, eski Android cihazlar (Android 6 ve önceki sürümler) tarafından kullanılan ve desteği sonlandırılmış bir OTA metodolojisidir. Bu cihazlarda, indirilen güncelleme paketini açmak ve güncellemeyi diğer bölümlere uygulamak için gereken yazılımı içeren özel bir kurtarma bölümü bulunur.
A/B bölümü olmayan eski Android cihazlarda, flash alanı genellikle aşağıdaki bölümleri içerir:
- önyükleme
-
Linux çekirdeğini ve minimum bir kök dosya sistemini (RAM diskine yüklenir) içerir. Sistem ve diğer bölümleri bağlar ve sistem bölümünde bulunan çalışma zamanını başlatır.
- sistem
-
Android Açık Kaynak Projesi'nde (AOSP) kaynak kodu bulunan sistem uygulamalarını ve kitaplıklarını içerir. Normal çalışma sırasında bu bölüm salt okunur olarak monte edilir; içeriği yalnızca OTA güncellemesi sırasında değişir.
- otomatik satış makinesi
-
Android Açık Kaynak Projesi'nde (AOSP) kaynak kodu bulunmayan sistem uygulamalarını ve kitaplıklarını içerir. Normal çalışma sırasında bu bölüm salt okunur olarak monte edilir; içeriği yalnızca OTA güncellemesi sırasında değişir.
- userdata
-
Kullanıcı tarafından yüklenen uygulamalar tarafından kaydedilen verileri vb. saklar. Bu bölüme normalde OTA güncelleme işlemi tarafından dokunulmaz.
- önbellek
-
Birkaç uygulama tarafından kullanılan geçici bekleme alanı (bu bölüme erişmek için özel uygulama izinleri gerekir) ve indirilen OTA güncelleme paketlerinin depolanması için kullanılır. Diğer programlar, dosyaların diledikleri zaman kaybolabileceği beklentisiyle bu alanı kullanır. Bazı OTA paketi yüklemeleri bu bölümün tamamen silinmesine neden olabilir. Önbellek, OTA güncellemesinden gelen güncelleme günlüklerini de içerir.
- kurtarma
-
Bir çekirdek ve bir paketi okuyup diğer bölümleri güncellemek için içeriğini kullanan özel kurtarma ikili dosyası da dahil olmak üzere ikinci bir tam Linux sistemi içerir.
- misc
-
OTA paketi uygulanırken cihazın yeniden başlatılması ihtimaline karşı, kurtarma işlemi tarafından ne yaptığıyla ilgili bazı bilgileri saklamak için kullanılan küçük bölüm.
OTA güncellemelerinin yaşam döngüsü
Tipik bir OTA güncellemesi aşağıdaki adımları içerir:
-
Cihaz, OTA sunucularıyla düzenli olarak iletişim kurar ve güncelleme paketinin URL'si ile kullanıcıya gösterilecek bir açıklama dizesi de dahil olmak üzere güncelleme kullanılabilirliği hakkında bilgilendirilir.
-
İndirilenleri bir önbelleğe veya veri bölümüne güncelleyin. Bu işlemin kriptografik imzası,
/system/etc/security/otacerts.zip içindeki sertifikalar ile doğrulanır. Kullanıcıdan güncellemeyi yüklemesi istenir.
-
Cihaz, önyükleme bölümündeki çekirdek yerine kurtarma bölümündeki çekirdeğin ve sistemin başlatıldığı kurtarma modunda yeniden başlatılır.
-
Kurtarma ikili dosyası, init tarafından başlatılır.
/cache/recovery/command dosyasında, indirilen pakete işaret eden komut satırı bağımsız değişkenlerini bulur.
-
Kurtarma, paketin kriptografik imzasını
/res/keys (kurtarma bölümündeki RAM diskinin bir parçası) içindeki ortak anahtarlarla karşılaştırarak doğrular.
-
Veriler paketten alınır ve gerektiğinde önyükleme, sistem ve/veya tedarikçi bölümünü güncellemek için kullanılır. Sistem bölümünde bırakılan yeni dosyalardan biri, yeni kurtarma bölümünün içeriğini içerir.
-
Cihaz normal şekilde yeniden başlatılır.
-
Yeni güncellenen önyükleme bölümü yüklenir ve yeni güncellenen sistem bölümündeki ikili dosyaları bağlayıp yürütmeye başlar.
-
Normal başlatma işleminin bir parçası olarak sistem, kurtarma bölümünün içeriğini istenen içeriklerle (daha önce
/system içinde dosya olarak depolanan) karşılaştırır. Bu içerikler farklı olduğundan kurtarma bölümü, istenen içeriklerle yeniden yüklenir. (Sonraki önyüklemelerde, kurtarma bölümü zaten yeni içeriği içerdiğinden yeniden yanıp sönme gerekmez.)
Sistem güncellemesi tamamlandı. Güncelleme günlüklerini /cache/recovery/last_log.# adresinde bulabilirsiniz.
Paketleri güncelleme
Güncelleme paketi, yürütülebilir ikili dosyayı META-INF/com/google/android/update-binary içeren bir .zip dosyasıdır. recovery, paketteki imzayı doğruladıktan sonra bu ikili dosyayı /tmp'a çıkarır ve aşağıdaki bağımsız değişkenleri ileterek ikili dosyayı çalıştırır:
-
Binary Authorization API sürüm numarasını güncelleyin. Güncelleme ikilisine iletilen bağımsız değişkenler değişirse bu sayı artar.
-
Komut borusunun dosya tanımlayıcısı. Güncelleme programı, bu boruyu kullanarak kurtarma ikilisine komut gönderebilir. Bu komutlar çoğunlukla kullanıcıya ilerleme durumunu göstermek gibi kullanıcı arayüzü değişiklikleri için kullanılır.
-
Güncelleme paketi
.zip dosyasının adı.
Güncelleme paketi, güncelleme ikili dosyası olarak statik olarak bağlı herhangi bir ikili dosyayı kullanabilir. OTA paket oluşturma araçları, birçok yükleme görevini yapabilecek basit bir komut dosyası dili sağlayan güncelleyici programını (bootable/recovery/updater) kullanır. Cihaz üzerinde çalışan diğer tüm ikili dosyaları değiştirebilirsiniz.
Güncelleme ikili dosyası, edify söz dizimi ve yerleşik işlevler hakkında ayrıntılı bilgi için OTA Paketlerinin İç Yapısı başlıklı makaleyi inceleyin.
Önceki sürümlerden taşıma
Android 2.3/3.0/4.0 sürümünden geçişte yapılan en önemli değişiklik, cihaza özgü tüm işlevlerin önceden tanımlanmış adlara sahip bir C işlevleri grubundan C++ nesnelerine dönüştürülmesidir.
Aşağıdaki tabloda, eski işlevler ve yaklaşık olarak eşdeğer bir amaca hizmet eden yeni yöntemler listelenmiştir:
| C işlevi |
C++ yöntemi |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
(ayrıca RecoveryUI::IsKeyPressed())
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
Eski işlevlerin yeni yöntemlere dönüştürülmesi oldukça basit bir işlemdir. Yeni make_device() sınıfınızın bir örneğini oluşturup döndürmek için yeni make_device() işlevini eklemeyi unutmayın.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
