به روز رسانی سیستم غیر A/B

در دستگاه‌های اندرویدی قدیمی‌تر بدون پارتیشن A/B، فضای فلش معمولاً شامل پارتیشن‌های زیر است:

چکمه
حاوی هسته لینوکس و حداقل سیستم فایل ریشه (بارگذاری شده در دیسک RAM) است. سیستم و پارتیشن‌های دیگر را سوار می‌کند و زمان اجرا واقع در پارتیشن سیستم را شروع می‌کند.
سیستم
شامل برنامه‌ها و کتابخانه‌های سیستمی است که دارای کد منبع در پروژه منبع باز Android (AOSP) هستند. در طول عملیات عادی، این پارتیشن فقط خواندنی نصب می شود. محتویات آن فقط در طول به روز رسانی OTA تغییر می کند.
فروشنده
شامل برنامه‌ها و کتابخانه‌های سیستمی است که کد منبع موجود در پروژه منبع باز Android (AOSP) را ندارند . در طول عملیات عادی، این پارتیشن فقط خواندنی نصب می شود. محتویات آن فقط در طول به روز رسانی OTA تغییر می کند.
داده های کاربر
داده های ذخیره شده توسط برنامه های نصب شده توسط کاربر و غیره را ذخیره می کند. این پارتیشن معمولاً توسط فرآیند به روز رسانی OTA لمس نمی شود.
حافظه پنهان
منطقه نگهداری موقت که توسط چند برنامه استفاده می شود (دسترسی به این پارتیشن به مجوزهای ویژه برنامه نیاز دارد) و برای ذخیره بسته های به روز رسانی OTA دانلود شده. برنامه های دیگر از این فضا با این انتظار استفاده می کنند که فایل ها می توانند در هر زمان ناپدید شوند. برخی از نصب های بسته OTA ممکن است منجر به پاک شدن کامل این پارتیشن شود. کش همچنین شامل گزارش‌های به‌روزرسانی از یک به‌روزرسانی OTA است.
بهبود
شامل دومین سیستم کامل لینوکس، شامل یک هسته و باینری بازیابی ویژه است که یک بسته را می خواند و از محتویات آن برای به روز رسانی پارتیشن های دیگر استفاده می کند.
متفرقه
پارتیشن کوچکی که توسط بازیابی برای مخفی کردن برخی از اطلاعات در مورد کارهایی که انجام می دهد در صورت راه اندازی مجدد دستگاه در حین اعمال بسته OTA استفاده می شود.

زندگی یک به روز رسانی OTA

یک به روز رسانی معمولی OTA شامل مراحل زیر است:

  1. دستگاه بررسی منظم را با سرورهای OTA انجام می دهد و از در دسترس بودن به روز رسانی، از جمله URL بسته به روز رسانی و یک رشته توضیحات برای نشان دادن به کاربر مطلع می شود.
  2. دانلودها را به حافظه پنهان یا پارتیشن داده به‌روزرسانی کنید و امضای رمزنگاری آن در برابر گواهی‌های موجود در /system/etc/security/otacerts.zip تأیید می‌شود. از کاربر خواسته می شود که به روز رسانی را نصب کند.
  3. دستگاه به حالت بازیابی مجدد راه اندازی می شود، که در آن هسته و سیستم در پارتیشن بازیابی به جای هسته در پارتیشن بوت بوت می شوند.
  4. باینری بازیابی توسط init شروع می شود. آرگومان های خط فرمان را در /cache/recovery/command پیدا می کند که آن را به بسته دانلود شده هدایت می کند.
  5. Recovery امضای رمزنگاری بسته را در برابر کلیدهای عمومی در /res/keys (بخشی از دیسک RAM موجود در پارتیشن بازیابی) تأیید می کند.
  6. داده ها از بسته خارج می شوند و در صورت لزوم برای به روز رسانی بوت، سیستم و/یا پارتیشن های فروشنده استفاده می شوند. یکی از فایل های جدید باقی مانده در پارتیشن سیستم حاوی محتویات پارتیشن بازیابی جدید است.
  7. دستگاه به طور معمول راه اندازی مجدد می شود.
    1. پارتیشن بوت به‌روزرسانی شده بارگیری می‌شود، و نصب می‌شود و اجرای باینری‌ها را در پارتیشن سیستم به‌روزرسانی‌شده جدید آغاز می‌کند.
    2. به عنوان بخشی از راه اندازی عادی، سیستم محتویات پارتیشن بازیابی را در برابر محتویات مورد نظر (که قبلاً به عنوان یک فایل در /system ذخیره می شد) بررسی می کند. آنها متفاوت هستند، بنابراین پارتیشن بازیابی با محتوای مورد نظر دوباره فلش می شود. (در بوت های بعدی، پارتیشن بازیابی از قبل حاوی محتویات جدید است، بنابراین نیازی به reflash نیست.)

به روز رسانی سیستم کامل شد! گزارش‌های به‌روزرسانی را می‌توانید در /cache/recovery/last_log. # .

بسته ها را به روز کنید

بسته به روز رسانی یک فایل .zip است که حاوی فایل اجرایی باینری META-INF/com/google/android/update-binary است. پس از تأیید امضای بسته، recovery این باینری را به /tmp استخراج می کند و باینری را اجرا می کند و آرگومان های زیر را ارسال می کند:

  • شماره نسخه API باینری را به روز کنید . اگر آرگومان های ارسال شده به باینری به روز رسانی تغییر کند، این عدد افزایش می یابد.
  • توصیف کننده فایل فرمان لوله . برنامه به روز رسانی می تواند از این لوله برای ارسال دستورات به باینری بازیابی استفاده کند، بیشتر برای تغییرات UI، مانند نشان دادن پیشرفت به کاربر.
  • نام فایل بسته به روز رسانی فایل .zip .

یک بسته به‌روزرسانی می‌تواند از هر باینری مرتبط استاتیک به عنوان باینری به‌روزرسانی استفاده کند. ابزارهای ساخت پکیج OTA از برنامه به‌روزرسانی ( bootable/recovery/updater ) استفاده می‌کنند که یک زبان برنامه‌نویسی ساده را فراهم می‌کند که می‌تواند بسیاری از کارهای نصب را انجام دهد. می توانید هر باینری دیگری را که روی دستگاه اجرا می شود جایگزین کنید.

برای جزئیات بیشتر در مورد باینری به‌روزرسانی‌کننده، ساختار نحوی و توابع داخلی، به Inside OTA Packages مراجعه کنید.

از نسخه های قبلی مهاجرت کنید

هنگام مهاجرت از نسخه اندروید 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() دستگاه::HandleMenuKey()
device_perform_action() Device::InvokeMenuItem()
device_wipe_data() Device::WipeData()
device_ui_init() ScreenRecoveryUI::Init()

تبدیل توابع قدیمی به روش های جدید باید به طور منطقی ساده باشد. فراموش نکنید که تابع new make_device() را برای ایجاد و برگرداندن نمونه ای از زیرکلاس Device جدید خود اضافه کنید.