আপডেট ম্যানেজার তার ভিএম (VM)-এর জন্য আপডেট সম্পাদন করে। আপডেট ম্যানেজার ক্লায়েন্টের সাথে সমন্বয় করে, যা সিস্টেম ইন্টিগ্রেটর সরবরাহ করে থাকে। ক্লায়েন্ট আপডেট পেলোড প্রদান করে এবং গাড়ির সার্বিক আপডেটের সমন্বয় সাধন করে। আপডেটটি নিম্নলিখিত ধাপগুলো নিয়ে গঠিত:
- প্রস্তুত: কোনো আপডেট চলছে না।
- প্রস্তুতি: আপডেট ম্যানেজার আপডেটটি ডিস্কে লিখে রাখে, কিন্তু এটিকে সক্রিয় করে না।
- সক্রিয় করুন: আপডেট ম্যানেজার প্রস্তুতকৃত আপডেটটিকে সক্রিয় করে, যাতে রিবুট করার পর এটি কার্যকর হয়।
- কমিট: আপডেট ম্যানেজার আপডেটটিকে স্থায়ী করে তোলে।
চিত্র ১. আপডেট ম্যানেজারের উচ্চ-স্তরের কার্যপ্রণালী।
আপডেট ম্যানেজার সিস্টেম আপডেট এবং সার্ভিস বান্ডেল আপডেট সমর্থন করে, যেগুলো এই পৃষ্ঠায় বর্ণনা করা হয়েছে।
সিস্টেম আপডেট
অ্যান্ড্রয়েড ওএস স্লট নামক দুই সেট পার্টিশন ব্যবহার করে, যার মধ্যে একবারে কেবল একটি স্লটই সক্রিয় থাকে। একটি সিস্টেম আপডেট নিষ্ক্রিয় স্লটে নতুন এক সেট পার্টিশন লিখে দেয় এবং পরবর্তী রিবুটে সিস্টেম সক্রিয় স্লটটি পরিবর্তন করে। সিস্টেম আপডেট তৈরি করার বিষয়ে আরও তথ্যের জন্য, এ/বি সিস্টেম আপডেট দেখুন।
পরিষেবা বান্ডেল আপডেট
AAOS SDV-তে, সার্ভিস বান্ডেলগুলো APEX-এর মধ্যে সার্ভিসগুলোকে একসাথে প্যাকেজ করে। সার্ভিস বান্ডেল আপডেটগুলো অস্থায়ী সেশনে নতুন APEX ফাইলগুলোকে প্রস্তুত করে। সিস্টেম রিবুট করার পর এই আপডেট করা বান্ডেলগুলো সক্রিয় হয়। সার্ভিস বান্ডেল APEX তৈরি করার বিষয়ে আরও তথ্যের জন্য, সার্ভিস বান্ডেল আপডেট দেখুন।
স্টেট মেশিন
ক্লায়েন্টের অনুরোধ এবং সিস্টেম পরিষেবা থেকে আসা ইভেন্টগুলো আপডেট ম্যানেজারের স্টেট মেশিনকে চালনা করে। আপডেট ম্যানেজারকে স্থিতিস্থাপক হিসেবে ডিজাইন করা হয়েছে, যা অপ্রত্যাশিত রিবুট বা ক্র্যাশের পরেও তার অবস্থা পুনরুদ্ধার করে এবং আপডেট প্রক্রিয়া পুনরায় শুরু করতে পারে।
চিত্র ২. আপডেট ম্যানেজার স্টেট মেশিন।
এপিআই
আপডেট ম্যানেজার একটি এপিআই (API) প্রদান করে যা স্টেট মেশিনের মাধ্যমে আপডেট প্রক্রিয়াটি পরিচালনা করে। এই এপিআইটি ভিএসআইডিএল (VSIDL) ব্যবহার করে, যা এসডিভি কমস (SDV Comms) সমর্থনকারী যেকোনো ভিএম-এ অবস্থিত ক্লায়েন্টদের সমর্থন করে এবং অনুরোধ ব্যর্থ হওয়ার বিজ্ঞপ্তি প্রদান করে।
নিরাপত্তা এবং প্রবেশাধিকার
সিস্টেমটি অনুমোদন নীতি ব্যবহার করে এপিআই (API) অ্যাক্সেস সীমাবদ্ধ করে। শুধুমাত্র অনুমোদিত ক্লায়েন্টই আপডেট ম্যানেজারে কল করতে পারে।
স্ট্যাটাস আপডেট
যেহেতু আপডেট অপারেশনগুলো দীর্ঘ সময় ধরে চলতে পারে, তাই আপডেট ম্যানেজার অ্যাসিঙ্ক্রোনাস স্ট্যাটাস আপডেট প্রদান করে। ক্লায়েন্টদের অবশ্যই স্ট্যাটাস আপডেটে সাবস্ক্রাইব করার মাধ্যমে অবস্থা পর্যবেক্ষণ করতে হবে।
সাবস্ক্রিপশন ব্যবস্থাপনা
সাবস্ক্রাইব করা: ক্লায়েন্টরা
SubscribeToStatusUpdates()মেথডটি কল করে স্ট্যাটাস আপডেটের জন্য সাবস্ক্রাইব করে:rpc SubscribeToStatusUpdates(SubscribeToStatusUpdatesRequest) returns (SubscribeToStatusUpdatesResponse) {} message SubscribeToStatusUpdatesRequest {} message SubscribeToStatusUpdatesResponse {}SubscribeToStatusUpdates()কল করার আগে, ক্লায়েন্টকে অবশ্যই একটি RPC ইন্টারফেস চালু করতে হবে যাUpdateManagerListenerServiceইমপ্লিমেন্ট করে।আনসাবস্ক্রাইব করা: ক্লায়েন্টরা
UnsubscribeFromStatusUpdates()কল করে স্ট্যাটাস আপডেট পাওয়া বন্ধ করতে পারেন।rpc UnsubscribeFromStatusUpdates(UnsubscribeFromStatusUpdatesRequest) returns (UnsubscribeFromStatusUpdatesResponse) {} message UnsubscribeFromStatusUpdatesRequest {} message UnsubscribeFromStatusUpdatesResponse {}
আপডেটম্যানেজারলিসেনারসার্ভিস
যেসব ক্লায়েন্ট 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 ফিল্ডটি ব্যবহার করে দুটি সম্ভাব্য বার্তার মধ্যে একটি প্রদান করে:
-
UpdateManagerStatus: আপডেট ম্যানেজারের অবস্থার পরিবর্তন হলে এটি পাঠানো হয়। -
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 মেসেজগুলো 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 রিকোয়েস্টটি পেলোড স্টেজ করার মাধ্যমে আপডেট প্রক্রিয়া শুরু করে, কিন্তু সিস্টেম আপডেটটি সক্রিয় করার জন্য অপেক্ষা করে:
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;
}
আপডেট ম্যানেজার ইনস্টলেশন-পরবর্তী ধাপগুলো চালানোর জন্য ক্লায়েন্ট কর্তৃক /data/ota_package ডিরেক্টরিতে প্রদত্ত OTA ইমেজটি প্রসেস করে, কিন্তু এটি সক্রিয় বুট স্লট পরিবর্তন করে না। এরপর সফল হলে এটি 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 এ পরিবর্তিত হয়, যা নির্দেশ করে যে VM-টি রিবুটের জন্য প্রস্তুত। অন্যথায়, স্টেটটি 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() অনুরোধটি করতে পারেন। প্রাথমিক অবস্থার উপর নির্ভর করে, সিস্টেম বিভিন্ন পদক্ষেপ গ্রহণ করে এবং বিভিন্ন অবস্থা অনুসরণ করে:
| রোলব্যাক জারি করার সময় অবস্থা | রাষ্ট্রীয় পরিবর্তন | সিস্টেম অ্যাকশন |
|---|---|---|
(শুধুমাত্র সিস্টেম আপডেটের জন্য) PREPARE , PREPARE_SUSPEND_COMPLETE | → PREPARE_CANCEL → PREPARE_ROLLBACK → READY | সিস্টেম আপডেট: সিস্টেম আপডেটটি বাতিল করে। |
PREPARE_FAILURE , PREPARE_COMPLETE | → PREPARE_ROLLBACK → READY | সিস্টেম আপডেট: সিস্টেম আপডেটটি বাতিল করে। সার্ভিস বান্ডেল আপডেট: স্টেজড APEX সেশন বাতিল করে। |
ACTIVATE_PRE_REBOOT_COMPLETE , ACTIVATE_PRE_REBOOT_FAILURE | → ACTIVATE_PRE_REBOOT_ROLLBACK → READY | ব্যবহারকারীর ডেটা চেকপয়েন্ট নিষ্ক্রিয় করে। সিস্টেম আপডেট: বুট স্লট পরিবর্তন বাতিল করে। সার্ভিস বান্ডেল আপডেট: স্টেজড APEX সরিয়ে দেয়। |
ACTIVATE_POST_REBOOT_COMPLETE | → ACTIVATE_POST_REBOOT_ROLLBACK → ACTIVATE_POST_REBOOT_ROLLBACK_COMPLETE | ব্যবহারকারীর ডেটা চেকপয়েন্ট নিষ্ক্রিয় করে। সিস্টেম আপডেট: বুট স্লটটি আগের অবস্থায় ফিরিয়ে দেয়। সার্ভিস বান্ডেল আপডেট: সক্রিয় APEX সেশনগুলোকে পূর্বাবস্থায় ফিরিয়ে আনে। রোলব্যাক কার্যকর হওয়ার জন্য একটি চূড়ান্ত রিবুট প্রয়োজন, যার পরে অবস্থাটি READY তে পরিবর্তিত হয়। |
প্রতিশ্রুতি
এই অনুরোধটি নির্দেশ করে যে আপডেটটি সফলভাবে সম্পন্ন হয়েছে এবং সমস্ত পরিবর্তন স্থায়ীভাবে প্রয়োগ করা হয়েছে।
rpc Commit(CommitRequest) returns (CommitResponse) {}
message CommitRequest {}
message CommitResponse {}
কমিট অ্যাকশনগুলো সম্পাদন করার সময় স্টেটটি COMMIT এ রূপান্তরিত হয়:
- সিস্টেম আপডেট: আপডেট ম্যানেজার বুটটিকে সফল হিসেবে চিহ্নিত করে, যা ভবিষ্যতে পূর্বাবস্থায় ফেরা প্রতিরোধ করে এবং পরবর্তী বুটগুলোতে এই স্লটটি নির্বাচন করে।
- সার্ভিস বান্ডেল আপডেট: আপডেট ম্যানেজার স্টেজড APEX সেশনটিকে সফল হিসেবে চিহ্নিত করে, আপডেট সেশনটি বন্ধ করে দেয় এবং বান্ডেলগুলোকে স্থায়ীভাবে সক্রিয় করে তোলে।
সিস্টেম আপডেটটি কমিট করার পর, আপডেট ম্যানেজার ইউজার ডেটা চেকপয়েন্টটি কমিট করে। এই বুটের সময় লেখা সমস্ত নতুন ইউজার ডেটা সিস্টেম স্থায়ী স্টোরেজে কমিট করে। আপডেট ম্যানেজার আবার READY অবস্থায় ফিরে আসে, যা নির্দেশ করে যে আপডেটটি সম্পন্ন হয়েছে।
APEX আনইনস্টল করুন
UninstallApex অনুরোধটি সার্ভিস বান্ডেলের /data সংস্করণটি মুছে ফেলে। আপনি যেকোনো অবস্থায় UninstallApex কল করতে পারেন, কিন্তু আনইনস্টল কার্যকর হওয়ার জন্য VM-টিকে অবশ্যই রিবুট করতে হবে। তাই, কোনো আপডেট চলাকালীন 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 {}