अपडेट मैनेजर

अपडेट मैनेजर, अपने वीएम के लिए अपडेट करता है. अपडेट मैनेजर, क्लाइंट के साथ मिलकर काम करता है. क्लाइंट, सिस्टम इंटिग्रेटर की ओर से उपलब्ध कराया जाता है. क्लाइंट, अपडेट पेलोड उपलब्ध कराता है और वाहन के अपडेट की पूरी प्रोसेस को मैनेज करता है. अपडेट की प्रोसेस में ये चरण शामिल हैं:

1. तैयार है: फ़िलहाल, कोई अपडेट नहीं हो रहा है.
2. तैयारी: अपडेट मैनेजर, अपडेट को डिस्क पर लिखता है. हालांकि, वह इसे चालू नहीं करता.
3. चालू करें: अपडेट मैनेजर, तैयार किए गए अपडेट को चालू करता है, ताकि रीबूट करने के बाद वह लागू हो जाए.
4. कमिट: अपडेट मैनेजर, अपडेट को हमेशा के लिए लागू करता है.

पहली इमेज. अपडेट मैनेजर के काम करने का तरीका.

अपडेट मैनेजर, सिस्टम अपडेट और सर्विस बंडल अपडेट की सुविधा देता है. इनके बारे में इस पेज पर बताया गया है.

सिस्टम अपडेट

Android OS, दो सेट वाले पार्टीशन का इस्तेमाल करता है. इन्हें स्लॉट कहा जाता है. एक बार में सिर्फ़ एक स्लॉट चालू होता है. सिस्टम अपडेट, बंद स्लॉट में पार्टीशन का नया सेट लिखता है. इसके बाद, सिस्टम अगली बार रीबूट होने पर, चालू स्लॉट को बदल देता है. सिस्टम अपडेट बनाने के बारे में ज़्यादा जानने के लिए, A/B सिस्टम अपडेट देखें.

सर्विस बंडल अपडेट

AAOS SDV में, सर्विस बंडल, APEX में सेवाओं को एक साथ पैकेज करते हैं. सर्विस बंडल अपडेट, अस्थायी सेशन में नई APEX फ़ाइलें स्टेज करते हैं. सिस्टम रीबूट होने के बाद, सिस्टम इन अपडेट किए गए बंडल को चालू करता है. सर्विस बंडल APEX बनाने के बारे में ज़्यादा जानने के लिए, सर्विस बंडल अपडेट देखें.

स्टेट मशीन

क्लाइंट के अनुरोधों और सिस्टम सेवाओं के इवेंट से, अपडेट मैनेजर की स्टेट मशीन चलती है. अपडेट मैनेजर को इस तरह से डिज़ाइन किया गया है कि वह अचानक रीबूट होने या क्रैश होने के बाद भी, अपनी स्थिति को वापस पा लेता है और अपडेट की प्रोसेस को फिर से शुरू कर देता है.

दूसरी इमेज. अपडेट मैनेजर की स्टेट मशीन.

एपीआई

अपडेट मैनेजर, एक एपीआई उपलब्ध कराता है. यह एपीआई, स्टेट मशीन के ज़रिए अपडेट की प्रोसेस को मैनेज करता है. एपीआई, VSIDL का इस्तेमाल करता है. यह SDV Comms की सुविधा देने वाले किसी भी वीएम में मौजूद क्लाइंट के साथ काम करता है. साथ ही, अनुरोध पूरा न होने पर सूचना भी देता है.

सुरक्षा और ऐक्सेस

सिस्टम, अनुमति देने वाली नीतियों का इस्तेमाल करके, एपीआई ऐक्सेस को सीमित करता है. सिर्फ़ अनुमति वाला क्लाइंट, अपडेट मैनेजर को कॉल कर सकता है.

चैनल से जुड़े अपडेट

अपडेट की कार्रवाइयों में ज़्यादा समय लग सकता है. इसलिए, अपडेट मैनेजर, स्टेटस अपडेट एसिंक्रोनस तरीके से उपलब्ध कराता है. क्लाइंट को स्टेटस अपडेट की सदस्यता लेकर, स्थिति पर नज़र रखनी चाहिए.

सदस्यता मैनेज करने की सुविधा देने वाले ऐप्लिकेशन

• सदस्यता लेना: क्लाइंट, SubscribeToStatusUpdates() तरीके को कॉल करके, स्टेटस अपडेट की सदस्यता लेते हैं:

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

  SubscribeToStatusUpdates() को कॉल करने से पहले, क्लाइंट को एक आरपीसी इंटरफ़ेस शुरू करना होगा, जो UpdateManagerListenerService को लागू करता है.

• सदस्यता छोड़ना: क्लाइंट, UnsubscribeFromStatusUpdates() को कॉल करके, स्टेटस अपडेट पाना बंद कर सकते हैं:

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

UpdateManagerListenerService

UpdateManagerService पर SubscribeToStatusUpdates() को कॉल करने वाले क्लाइंट को, स्टेटस अपडेट पाने के लिए यह सेवा लागू करनी होगी:

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: यह तब भेजा जाता है, जब अपडेट मैनेजर की स्थिति बदलती है.
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: यह सिस्टम अपडेट के दौरान, अपडेट इंजन से मौजूदा स्टेटस के बारे में बताता है:

  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;
  }
  
  

तुरंत स्टेटस पाना

GetStatus() को कॉल करके, मौजूदा स्थिति और पेलोड को किसी भी समय वापस पाया जा सकता है. SystemUpdatePayload और ServiceBundleUpdatePayload मैसेज के बारे में, तैयारी करें में बताया गया है.

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 अनुरोध, पेलोड को स्टेज करके अपडेट की प्रोसेस शुरू करता है. हालांकि, सिस्टम, अपडेट को चालू करने के लिए इंतज़ार करता है:

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 स्थिति में मान्य है.

• रोकें: अपडेट को रोकता है. साथ ही, स्थिति को 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 फ़ाइलों पर सही तरीके से हस्ताक्षर किए गए हैं और उन्हें किसी सेशन में स्टेज करता है. अपडेट पूरा होने पर, स्थिति 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 में बदल जाती है.

रीबूट के बाद

रीबूट होने के बाद, सिस्टम चेकपॉइंट मोड में शुरू होता है. इस मोड में, सिस्टम, उपयोगकर्ता के डेटा वाले पार्टीशन में किए गए किसी भी बदलाव को परमानेंट स्टोरेज में कमिट नहीं करता. अगर सिस्टम, अपडेट को सफलतापूर्वक कमिट नहीं करता है, तो वह इन बदलावों को शुरुआती स्थिति में वापस ले जाता है.

बूट की सीमा

सिस्टम, उपयोगकर्ता के डेटा वाले पार्टीशन में किए गए बदलावों को इन स्थितियों में वापस ले जाता है:

• क्लाइंट, साफ़ तौर पर Rollback() अनुरोध भेजता है और सिस्टम को रीबूट करता है.
• क्लाइंट, Commit() या Rollback() को कॉल किए बिना, सिस्टम बहुत बार बूट होता है. हर अपडेट टाइप के लिए, बूट की सीमा अलग-अलग होती है:
  • सिस्टम अपडेट: BootControl लागू करने से यह सीमा सेट होती है. उदाहरण के लिए, Cuttlefish डिवाइसों में इस्तेमाल किए जाने वाले लागू करने की डिफ़ॉल्ट सीमा, सात बूट होती है.
  • सर्विस बंडल अपडेट: क्लाइंट की ओर से उपलब्ध कराए गए ServiceBundleUpdatePayload का boot_attempts फ़ील्ड, 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 में बदल जाती है:

• सिस्टम अपडेट: अपडेट मैनेजर, बूट को सफल के तौर पर मार्क करता है. इससे, भविष्य में रोलबैक नहीं किया जा सकेगा और इसके बाद के बूट में यह स्लॉट चुना जाएगा.
• सर्विस बंडल अपडेट: अपडेट मैनेजर, स्टेज किए गए 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 {}