مدیر به‌روزرسانی

مدیر به‌روزرسانی، به‌روزرسانی‌ها را برای ماشین مجازی خود انجام می‌دهد. مدیر به‌روزرسانی با کلاینت که توسط یکپارچه‌ساز سیستم ارائه می‌شود، هماهنگ می‌شود. کلاینت، محتوای به‌روزرسانی را ارائه می‌دهد و به‌روزرسانی کلی خودرو را هماهنگ می‌کند. به‌روزرسانی شامل این مراحل است:

1. آماده: هیچ به‌روزرسانی در حال انجام نیست.
2. آماده‌سازی: مدیر به‌روزرسانی، به‌روزرسانی را روی دیسک می‌نویسد، اما آن را فعال نمی‌کند.
3. فعال‌سازی: مدیر به‌روزرسانی، به‌روزرسانی آماده‌شده را فعال می‌کند تا پس از راه‌اندازی مجدد، اعمال شود.
4. COMMIT: مدیر به‌روزرسانی، به‌روزرسانی را دائمی می‌کند.

شکل ۱. عملیات سطح بالای مدیر به‌روزرسانی.

مدیر به‌روزرسانی از به‌روزرسانی‌های سیستم و به‌روزرسانی‌های بسته‌های خدماتی پشتیبانی می‌کند که در این صفحه توضیح داده شده‌اند.

به‌روزرسانی‌های سیستم

سیستم عامل اندروید از دو مجموعه پارتیشن به نام اسلات استفاده می‌کند که در هر زمان فقط یکی از اسلات‌ها فعال است. یک به‌روزرسانی سیستم، مجموعه‌ای جدید از پارتیشن‌ها را در اسلات غیرفعال می‌نویسد و سیستم در راه‌اندازی مجدد بعدی، اسلات فعال را تغییر می‌دهد. برای اطلاعات بیشتر در مورد ایجاد به‌روزرسانی‌های سیستم، به به‌روزرسانی‌های سیستم A/B مراجعه کنید.

به‌روزرسانی‌های بسته‌های خدماتی

در AAOS SDV، سرویس‌ها، سرویس‌ها را درون APEXها بسته‌بندی می‌کنند. به‌روزرسانی‌های بسته سرویس، فایل‌های APEX جدید را در sessionهای موقت استیج می‌کنند. سیستم پس از راه‌اندازی مجدد سیستم، این بسته‌های به‌روزرسانی‌شده را فعال می‌کند. برای اطلاعات بیشتر در مورد ساخت APEXهای بسته سرویس، به به‌روزرسانی‌های بسته سرویس مراجعه کنید.

ماشین حالت

درخواست‌های کلاینت و رویدادهای سرویس‌های سیستم، ماشین وضعیت Update Manager را هدایت می‌کنند. Update Manager به گونه‌ای طراحی شده است که انعطاف‌پذیر باشد، وضعیت خود را بازیابی کند و فرآیند به‌روزرسانی را حتی پس از راه‌اندازی مجدد یا خرابی‌های غیرمنتظره از سر بگیرد.

شکل ۲. دستگاه وضعیت مدیر به‌روزرسانی.

رابط برنامه‌نویسی کاربردی

مدیر به‌روزرسانی یک API ارائه می‌دهد که فرآیند به‌روزرسانی را از طریق ماشین وضعیت هدایت می‌کند. این API از VSIDL استفاده می‌کند که از کلاینت‌های مستقر در هر ماشین مجازی که از ارتباطات SDV پشتیبانی می‌کند، پشتیبانی می‌کند و اعلان‌های مربوط به شکست درخواست را ارائه می‌دهد.

امنیت و دسترسی

سیستم با استفاده از سیاست‌های مجوزدهی، دسترسی به API را محدود می‌کند. فقط کلاینت مجاز می‌تواند با Update Manager تماس برقرار کند.

به‌روزرسانی‌های وضعیت

از آنجا که عملیات به‌روزرسانی می‌تواند طولانی مدت باشد، مدیر به‌روزرسانی، به‌روزرسانی‌های وضعیت ناهمزمان را ارائه می‌دهد. کلاینت‌ها باید با عضویت در به‌روزرسانی‌های وضعیت، وضعیت را رصد کنند.

مدیریت اشتراک

• اشتراک: کلاینت‌ها با فراخوانی متد SubscribeToStatusUpdates() در به‌روزرسانی‌های وضعیت مشترک می‌شوند:

  rpc SubscribeToStatusUpdates(SubscribeToStatusUpdatesRequest)
      returns (SubscribeToStatusUpdatesResponse) {}
  
  message SubscribeToStatusUpdatesRequest {}
  
  message SubscribeToStatusUpdatesResponse {}
  

  قبل از فراخوانی SubscribeToStatusUpdates() ، کلاینت باید یک رابط RPC که UpdateManagerListenerService پیاده‌سازی می‌کند، آغاز کند.

• لغو اشتراک: کلاینت‌ها می‌توانند با فراخوانی UnsubscribeFromStatusUpdates() دریافت به‌روزرسانی‌های وضعیت را متوقف کنند:

  rpc UnsubscribeFromStatusUpdates(UnsubscribeFromStatusUpdatesRequest)
      returns (UnsubscribeFromStatusUpdatesResponse) {}
  
  message UnsubscribeFromStatusUpdatesRequest {}
  
  message UnsubscribeFromStatusUpdatesResponse {}
  

سرویس UpdateManagerListener

کلاینت‌هایی که تابع SubscribeToStatusUpdates() را در UpdateManagerService فراخوانی می‌کنند، باید سرویس زیر را برای دریافت به‌روزرسانی‌های وضعیت پیاده‌سازی کنند:

service UpdateManagerListenerService {
  /* Called when there is a status update from the Update Manager. */
  rpc OnStatusUpdate(OnStatusUpdateRequest) returns (OnStatusUpdateResponse) {}
}

message OnStatusUpdateRequest {
  oneof status_update {
    UpdateManagerStatus update_manager_status = 1;
    UpdateProgress update_progress = 2;
  }
}

message OnStatusUpdateResponse {}

OnStatusUpdateRequest یکی از دو پیام ممکن را با استفاده از فیلد status_update ارائه می‌دهد:

1. UpdateManagerStatus : زمانی ارسال می‌شود که وضعیت Update Manager تغییر کند.
2. UpdateProgress : برای نشان دادن پیشرفت به‌روزرسانی در طول حالت‌های PREPARE و ACTIVATE_PRE_REBOOT ارسال می‌شود، زیرا این فرآیند می‌تواند زمان قابل توجهی طول بکشد.

پیام‌های وضعیت و خطا

پیام‌های وضعیت شامل جزئیاتی در مورد وضعیت و هرگونه خرابی هستند:

• UpdateManagerStatus : مرحله فعلی به‌روزرسانی و هر دلیل شکست را گزارش می‌دهد:

  message UpdateManagerStatus {
    /* The current state of the update */
    UpdateState update_state = 1;
    /* The reason for the failure, if the update failed */
    FailureReason failure_reason = 2;
  }
  
  enum UpdateState {
    /* The Update Manager is ready to accept a new update. */
    READY = 0;
    /* An update is being prepared. */
    PREPARE = 1;
    /* The update failed during the prepare step. Roll back the update to start a
     *   new update. */
    PREPARE_FAILURE = 2;
    /* The update was prepared successfully. */
    PREPARE_COMPLETE = 3;
    /* A rollback has started from the prepare step. When complete, transitions
     *   to READY. */
    PREPARE_ROLLBACK = 4;
    /* The prepared update is being activated. */
    ACTIVATE_PRE_REBOOT = 5;
    /* The update failed during the activate step before the reboot. Roll back the
     *   update to start a new update. */
    ACTIVATE_PRE_REBOOT_FAILURE = 6;
    /* The update was activated successfully. Reboot to complete activation. */
    ACTIVATE_PRE_REBOOT_COMPLETE = 7;
    /* A rollback has started from the activate pre-reboot step. When complete,
     *   transitions to READY. */
    ACTIVATE_PRE_REBOOT_ROLLBACK = 8;
    /* An update was successfully activated after the reboot. The update needs to
     *   be committed or rolled back to be completed. */
    ACTIVATE_POST_REBOOT_COMPLETE = 9;
    /* A rollback has started from the activate post-reboot step. */
    ACTIVATE_POST_REBOOT_ROLLBACK = 10;
    /* The rollback was completed successfully. Reboot to complete the
     *   rollback. */
    ACTIVATE_POST_REBOOT_ROLLBACK_COMPLETE = 11;
    /* The update is being committed. When complete, transitions to READY */
    COMMIT = 12;
    /* The prepare request is being cancelled */
    PREPARE_CANCEL = 13;
    /* The system update has started suspending */
    PREPARE_SUSPEND = 14;
    /* The system update has finished suspending */
    PREPARE_SUSPEND_COMPLETE = 15;
  }
  
  message FailureReason {
    /* The original error that triggered the failure */
    ErrorCode error_code = 1;
    /* Binder error message for most ErrorCodes. */
    string error_message = 2;
  }
  
  enum ErrorCode {
    Unspecified = 0;
    /* Error from UpdateEngine service */
    UpdateEngineError = 1;
    // Error from the ApexService
    ApexServiceError = 2;
    // Error from the BootControlService
    BootControlServiceError = 3;
    // Error from the VoldService
    VoldServiceError = 4;
  }
  

• UpdateProgress : وضعیت فعلی را از Update Engine در حین به‌روزرسانی‌های سیستم گزارش می‌دهد:

  message UpdateProgress {
    /* Matches the enum UpdateStatus from the UpdateEngine service. */
    int32 status_code = 1;
  
    /* A value ranging from 0.0 to 1.0, 1.0 representing the process is complete. */
    float percentage = 2;
  }
  
  

دریافت وضعیت فوری

شما می‌توانید وضعیت فعلی و میزان بار داده (payload) را در هر زمانی با فراخوانی GetStatus() بازیابی کنید. پیام‌های SystemUpdatePayload و ServiceBundleUpdatePayload در Prepare توضیح داده شده‌اند.

rpc GetStatus(GetStatusRequest) returns (GetStatusResponse) {}

message GetStatusRequest {}

message GetStatusResponse {
  /* The status of the Update Manager */
  UpdateManagerStatus update_manager_status = 1;
  /* The current update payload, if one has been set through the Prepare() request */
  oneof payload {
    SystemUpdatePayload system_update_payload = 2;
    ServiceBundleUpdatePayload service_bundle_update_payload = 3;
  }
}

آماده سازی

درخواست Prepare فرآیند به‌روزرسانی را با مرحله‌بندی payload آغاز می‌کند، اما سیستم منتظر می‌ماند تا به‌روزرسانی را فعال کند:

rpc Prepare(PrepareRequest) returns (PrepareResponse) {}

message PrepareRequest {
  oneof payload {
    SystemUpdatePayload system_update_payload = 1;
    ServiceBundleUpdatePayload service_bundle_update_payload = 2;
  }
}

message PrepareResponse {}

اگر درخواست معتبر باشد، وضعیت به PREPARE تغییر می‌کند و مدیر به‌روزرسانی، به‌روزرسانی را آغاز می‌کند.

نوع بار داده، نوع به‌روزرسانی را تعیین می‌کند.

بار به‌روزرسانی سیستم

یک به‌روزرسانی سیستم از داده‌های SystemUpdatePayload استفاده می‌کند که به مسیری برای یک تصویر به‌روزرسانی از طریق هوا (OTA) نیاز دارد. پارامترهای دیگر از تصویر تجزیه می‌شوند، اما می‌توانید آنها را طوری تعیین کنید که مقادیر تجزیه شده را نادیده بگیرند.

message SystemUpdatePayload {
  /* Absolute path to the update image (e.g., /updates/ota_update.zip) */
  string payload = 1;

  /* Offset (in bytes) into the payload where the payload binary starts. */
  optional int64 payload_offset = 2;

  /* The amount of data (in bytes) to read from "payload" as the update payload. */
  optional int64 payload_size = 3;

  /* The header key value pairs to apply with the payload. */
  map<string, string> header_key_value_pairs = 4;
}

مدیر به‌روزرسانی، تصویر OTA (که توسط کلاینت در دایرکتوری /data/ota_package ارائه شده است) را برای اجرای مراحل پس از نصب پردازش می‌کند، اما اسلات بوت فعال را تغییر نمی‌دهد. سپس در صورت موفقیت به حالت PREPARE_COMPLETE یا در صورت شکست به حالت PREPARE_FAILURE منتقل می‌شود.

تعلیق به‌روزرسانی سیستم

شما می‌توانید فرآیند به‌روزرسانی را فقط برای به‌روزرسانی‌های سیستم متوقف کنید. این درخواست فقط زمانی معتبر است که در حالت PREPARE .

• Suspend: به‌روزرسانی را متوقف می‌کند و وضعیت را از طریق PREPARE_SUSPEND منتقل می‌کند.

  rpc Suspend(SuspendRequest) returns (SuspendResponse) {}
  
  message SuspendRequest {}
  
  message SuspendResponse {}
  

  در صورت موفقیت، وضعیت به PREPARE_SUSPEND_COMPLETE تغییر می‌کند. در صورت شکست، وضعیت به PREPARE_FAILURE تغییر می‌کند.

• ادامه: به‌روزرسانی متوقف‌شده را ادامه می‌دهد. این فقط در حالت PREPARE_SUSPEND_COMPLETE معتبر است.

  rpc Resume(ResumeRequest) returns (ResumeResponse) {}
  
  message ResumeRequest {}
  
  message ResumeResponse {}
  

  وضعیت به حالت PREPARE برمی‌گردد.

بار به‌روزرسانی بسته سرویس

به‌روزرسانی بسته‌ی سرویس از ServiceBundleUpdatePayload استفاده می‌کند که شامل مسیرهای فایل‌های APEX است و محدودیت تعداد دفعات تلاش برای فعال‌سازی را تعیین می‌کند.

message ServiceBundleUpdatePayload {
  /* Absolute path to an .apex file. Multiple .apex files can be included. */
  repeated string apex_path = 1;

  /* Number of boots to attempt activation before aborting. Must be > 0. */
  int32 boot_attempts = 2;
}

مدیر به‌روزرسانی تأیید می‌کند که فایل‌های APEX به درستی امضا شده‌اند و آنها را در یک جلسه (session) قرار می‌دهد. در صورت موفقیت، وضعیت به PREPARE_COMPLETE تغییر می‌کند. در صورت شکست، وضعیت به PREPARE_FAILURE تغییر می‌کند.

فعال کردن

درخواست Activate به‌روزرسانی آماده‌شده را در راه‌اندازی مجدد بعدی فعال می‌کند.

rpc Activate(ActivateRequest) returns (ActivateResponse) {}

message ActivateRequest {}

message ActivateResponse {}

پیش راه اندازی مجدد

مدیر به‌روزرسانی هنگام فعال‌سازی به‌روزرسانی به حالت ACTIVATE_PRE_REBOOT می‌رود. مدیر به‌روزرسانی همچنین یک نقطه بررسی داده‌های کاربر ایجاد می‌کند که هنگام راه‌اندازی مجدد سیستم اعمال می‌شود.

اقدامات فعال‌سازی بسته به نوع به‌روزرسانی متفاوت است:

• به‌روزرسانی سیستم: سیستم مراحل پس از نصب را اجرا می‌کند و اسلات بوت را برای روشن کردن راه‌اندازی مجدد بعدی تنظیم می‌کند.
• به‌روزرسانی بسته‌ی سرویس: سیستم، جلسه‌ی APEX مرحله‌بندی‌شده را به‌عنوان آماده‌ی فعال‌سازی علامت‌گذاری می‌کند.

اگر سیستم با موفقیت به‌روزرسانی را فعال کند، وضعیت به ACTIVATE_PRE_REBOOT_COMPLETE تغییر می‌کند که نشان می‌دهد ماشین مجازی آماده راه‌اندازی مجدد است. در غیر این صورت، وضعیت به ACTIVATE_PRE_REBOOT_FAILURE تغییر می‌کند.

پس از راه‌اندازی مجدد

پس از راه‌اندازی مجدد، سیستم در حالت ایست بازرسی (checkpoint mode) شروع به کار می‌کند. در این حالت، سیستم هیچ تغییری را در پارتیشن داده‌های کاربر در حافظه دائمی ثبت نمی‌کند. اگر سیستم به‌روزرسانی را با موفقیت انجام ندهد، این تغییرات را به حالت اولیه برمی‌گرداند.

محدودیت بوت

سیستم در هر یک از این شرایط، تغییرات را به پارتیشن داده‌های کاربر برمی‌گرداند:

• کلاینت یک درخواست صریح Rollback() ارسال می‌کند و سیستم را مجدداً راه‌اندازی می‌کند.
• سیستم بدون فراخوانی Commit() یا Rollback() توسط کلاینت، بارها بوت می‌شود. محدودیت بوت برای هر نوع به‌روزرسانی متفاوت است:
  • به‌روزرسانی سیستم: پیاده‌سازی BootControl این را تنظیم می‌کند. برای مثال، محدودیت پیش‌فرض در پیاده‌سازی مورد استفاده توسط دستگاه‌های Cuttlefish، هفت بوت است.
  • به‌روزرسانی بسته‌ی سرویس: فیلد boot_attempts از ServiceBundleUpdatePayload که توسط کلاینت ارائه می‌شود، این مقدار را هنگام ارسال درخواست Prepare() تنظیم می‌کند.

تأیید

سپس سیستم به‌روزرسانی را تأیید می‌کند:

• به‌روزرسانی سیستم: dm-verity اسلات به‌روزرسانی‌شده را از نظر خرابی بررسی می‌کند.
• به‌روزرسانی بسته سرویس: apexd امضای هر APEX را بررسی می‌کند و تصویر APEX را روی سیستم فایل نصب می‌کند.

اگر تأیید موفقیت‌آمیز باشد، وضعیت به ACTIVATE_POST_REBOOT_COMPLETE تغییر می‌کند. مدیر به‌روزرسانی منتظر یکی از دو Commit() یا Rollback() می‌ماند.

اگر تأیید ناموفق باشد، سیستم مجدداً راه‌اندازی می‌شود. وقتی سیستم به حد مجاز بوت رسید، سیستم به حالت اولیه برمی‌گردد:

• به‌روزرسانی سیستم: سیستم به اسلات اصلی برمی‌گردد.
• به‌روزرسانی بسته‌ی سرویس: APEXهای به‌روزرسانی‌شده حذف می‌شوند و APEXهای اصلی دوباره فعال می‌شوند.

اگر تأیید برای هر نوع به‌روزرسانی ناموفق باشد، وضعیت پس از بازیابی وضعیت اصلی به ACTIVATE_PRE_REBOOT_FAILURE تغییر می‌کند.

عقبگرد

درخواست Rollback شروع به بازگرداندن سیستم به حالت قبل از به‌روزرسانی می‌کند.

rpc Rollback(RollbackRequest) returns (RollbackResponse) {}

message RollbackRequest {}

message RollbackResponse {}

شما می‌توانید درخواست Rollback() را در حالت‌های مختلفی انجام دهید. بسته به حالت اولیه، سیستم اقدامات متفاوتی انجام می‌دهد و حالت‌های مختلفی به دنبال آن ایجاد می‌شوند:

متعهد شدن

این درخواست نشان می‌دهد که به‌روزرسانی با موفقیت انجام شده و تمام تغییرات به طور دائم اعمال می‌شوند.

rpc Commit(CommitRequest) returns (CommitResponse) {}

message CommitRequest {}

message CommitResponse {}

هنگام انجام اقدامات commit، وضعیت به COMMIT تغییر می‌کند:

• به‌روزرسانی سیستم: مدیر به‌روزرسانی، بوت را به عنوان موفقیت‌آمیز علامت‌گذاری می‌کند که از بازگشت به حالت اولیه در آینده جلوگیری می‌کند و این اسلات را در بوت‌های بعدی انتخاب می‌کند.
• به‌روزرسانی بسته‌ی سرویس: مدیر به‌روزرسانی، جلسه‌ی APEX مرحله‌بندی‌شده را به‌عنوان موفقیت‌آمیز علامت‌گذاری می‌کند، جلسه‌ی به‌روزرسانی را می‌بندد و بسته‌ها را به‌طور دائم فعال می‌کند.

پس از اینکه سیستم به‌روزرسانی را انجام داد، مدیر به‌روزرسانی، نقطه بررسی داده‌های کاربر را انجام می‌دهد. سیستم تمام داده‌های جدید کاربر را که در طول این بوت نوشته شده است، در حافظه دائمی قرار می‌دهد. مدیر به‌روزرسانی به READY برمی‌گردد که نشان می‌دهد به‌روزرسانی کامل شده است.

APEXها را حذف نصب کنید

درخواست UninstallApex نسخه /data از بسته‌های سرویس را حذف می‌کند. می‌توانید در هر حالتی UninstallApex فراخوانی کنید، اما برای اعمال حذف، ماشین مجازی باید مجدداً راه‌اندازی شود. بنابراین، در حین انجام به‌روزرسانی، از فراخوانی UninstallApex خودداری کنید. UninstallApex APEXهای از پیش نصب شده را حذف نمی‌کند، داده‌های APEX را پاک نمی‌کند یا نسخه‌های غیرفعال APEX را حذف نمی‌کند.

rpc UninstallApex(UninstallApexRequest) returns (UninstallApexResponse) {}

message UninstallApexRequest {
  message ApexInfo {
    string module_name = 1;
    int64 version_code = 2;
  }
  repeated ApexInfo apexes = 1;
}

message UninstallApexResponse {}