सिस्टम अपडेट मैनेज करना

डेवलपर के लिए बनी इस गाइड में बताया गया है कि आपका डिवाइस नीति नियंत्रक (डीपीसी), डिवाइस के उपयोगकर्ता की ओर से Android सिस्टम के अपडेट को कैसे मैनेज कर सकता है.

परिचय

Android डिवाइस, ओवर-द-एयर (ओटीए) अपडेट पा सकते हैं और इंस्टॉल कर सकते हैं की ज़रूरत नहीं पड़ती. Android, डिवाइस इस्तेमाल करने वाले व्यक्ति को सिस्टम अपडेट होने की सूचना देता है उपलब्ध हो और डिवाइस उपयोगकर्ता इस अपडेट को तुरंत या बाद में इंस्टॉल कर सकता है.

आपके DPC की मदद से आईटी एडमिन, डिवाइस इस्तेमाल करने वाले व्यक्ति के लिए सिस्टम अपडेट मैनेज कर सकता है. DPC उसके पास पूरी तरह से मैनेज किया जा रहा डिवाइस हो सकता है. इसे डिवाइस का मालिक कहा जाता है. इसके अलावा, उसके पास वर्क प्रोफ़ाइल का मालिकाना हक हो सकता है (जिसे प्रोफ़ाइल का मालिक कहा जाता है). टेबल 1 में बताया गया है कि डिवाइस के मालिक, सिस्टम अपडेट को कैसे मैनेज कर सकते हैं. वहीं, प्रोफ़ाइल के मालिक सिर्फ़ सिस्टम अपडेट की जानकारी की शिकायत कर सकते हैं.

टेबल 1: डीपीसी के लिए उपलब्ध टास्क, मालिकाना हक के मोड पर निर्भर करते हैं

देखें कि क्या कोई अपडेट बाकी है

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

Android 8.0 (एपीआई लेवल 26) या इसके बाद के वर्शन पर काम करने वाले डिवाइस के मालिक और प्रोफ़ाइल के मालिक यह देख सकता है कि डिवाइस में कोई सिस्टम अपडेट इंस्टॉल है या नहीं. कॉल करें DevicePolicyManager.getPendingSystemUpdate() जो डिवाइस के अप-टू-डेट होने पर null दिखाता है. अगर सिस्टम अपडेट बाकी है, तो यह तरीका अपडेट के बारे में जानकारी दिखाता है.

ऐसे अपडेट के बारे में ज़्यादा जानें जिसे मंज़ूरी मिलना बाकी है

getPendingSystemUpdate() को कॉल करने के बाद, लौटाए गए आइटम की जांच की जा सकती है बचे हुए अपडेट के बारे में ज़्यादा जानकारी पाने के लिए, SystemUpdateInfo वैल्यू. कॉन्टेंट बनाने नीचे दिए गए उदाहरण में बताया गया है कि बचे हुए अपडेट के पहले होने का पता कैसे लगाया जा सकता है डिवाइस पर उपलब्ध है:

val firstAvailable =
        dpm.getPendingSystemUpdate(adminName)?.receivedTime
firstAvailable?.let {
    Log.i(TAG, "Update first available: ${Date(firstAvailable)}")
}

SystemUpdateInfo updateInfo = dpm.getPendingSystemUpdate(adminName);
if (updateInfo != null) {
  Long firstAvailable = updateInfo.getReceivedTime();
  Log.i(TAG, "Update first available: " + new Date(firstAvailable));
}

सिस्टम कॉलबैक

जब कोई अपडेट उपलब्ध होता है, तो Android सिस्टम डिवाइस के मालिकों को नए अपडेट के बारे में सूचना देता है. Android 8.0 या उसके बाद के वर्शन में, सिस्टम प्रोफ़ाइल के मालिकों को भी इसकी सूचना देता है.

अपने DeviceAdminReceiver सबक्लास में, onSystemUpdatePending() कॉलबैक को बदलें. कॉलबैक पाने के लिए, आपको अपने डीपीसी को रजिस्टर करने या उसका विज्ञापन देने की ज़रूरत नहीं है. सिस्टम शायद किसी एक अपडेट के लिए इस तरीके को एक से ज़्यादा बार कॉल करें. इसलिए, अपडेट का स्टेटस देखें देखें. कॉलबैक में सिस्टम अपडेट के बारे में ज़्यादा जानने के लिए, getPendingSystemUpdate() पर कॉल करें. नीचे दिए गए उदाहरण में बताया गया है कि ऐसा कैसे किया जा सकता है:

/**
 * Called when a new update is available.
 */
override fun onSystemUpdatePending(context: Context?, intent: Intent?,
                                   receivedTime: Long) {

    // System update information is supported in API level 26 or higher.
    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
        return
    }

    val updateInfo = getManager(context)
            .getPendingSystemUpdate(getWho(context))
            ?: return
    if (updateInfo.securityPatchState ==
            SystemUpdateInfo.SECURITY_PATCH_STATE_TRUE) {
        // Perhaps install because this is a security patch.
        // ...
    }
}

/**
 * Called when a new update is available.
 */
public void onSystemUpdatePending (Context context, Intent intent,
                                   long receivedTime) {

  // System update information is supported in API level 26 or higher.
  if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
    return;
  }
  SystemUpdateInfo updateInfo = getManager(context)
      .getPendingSystemUpdate(getWho(context));
  if (updateInfo == null) {
    return;
  }
  if (updateInfo.getSecurityPatchState() ==
      SystemUpdateInfo.SECURITY_PATCH_STATE_TRUE) {
    // Perhaps install because this is a security patch.
    // ...
  }
}

अगर किसी सिस्टम में एक से ज़्यादा डीपीसी हैं, तो डिवाइस के मालिक और प्रोफ़ाइल के मालिक, दोनों को कॉलबैक मिलता है. उदाहरण के लिए, पूरी तरह से मैनेज किए जाने वाले डिवाइसों पर वर्क प्रोफ़ाइल.

नीतियां अपडेट करना

डिवाइस का मालिक, लोकल सिस्टम सेट करके यह कंट्रोल कर सकता है कि अपडेट कब इंस्टॉल किए जाएं नीति अपडेट करें. सिस्टम अपडेट की नीति, इन तीन में से किसी एक तरह की हो सकती है:

अपने-आप

सिस्टम अपडेट होते ही इंस्टॉल हो जाता है उपलब्ध है (उपयोगकर्ता के इंटरैक्शन के बिना). इस नीति को सेट करने पर, ऐसे अपडेट तुरंत इंस्टॉल हो जाते हैं जिन्हें मंज़ूरी मिलना बाकी है जिन्हें टाला जा सकता है या मेंटेनेंस विंडो का इंतज़ार किया जा सकता है.

विंडो में

यह हर दिन के रखरखाव की विंडो के दौरान, सिस्टम अपडेट इंस्टॉल करता है. इसके लिए, उपयोगकर्ता की ज़रूरत नहीं होती. विंडो वाली नई नीति बनाते समय, हर दिन के लिए मेंटेनेंस विंडो के शुरू और खत्म होने का समय, दिन के मिनटों के तौर पर सेट करें.

फ़िलहाल के लिए टाला गया

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

पेमेंट के लिए तय की गई अवधि को आगे बढ़ाने की अवधियां

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

स्थगित होने के अलावा, हो सकता है कि Android अन्य ऐप्लिकेशन के लिए कोई अपडेट इंस्टॉल न कर पाए कनेक्टिविटी न होने, डिस्क में कम स्टोरेज होने या बैटरी कम होने जैसी वजहों से.

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

नीति सेट करने का तरीका

Android 8.0 (एपीआई लेवल 26) या इसके बाद के वर्शन में, अपडेट से जुड़ी नीतियां सेट की जा सकती हैं. यह तय करने के लिए डिवाइस में सिस्टम अपडेट इंस्टॉल होने के बाद, एक इंस्टेंस बनाएं SystemUpdatePolicy, आउटलाइन किए गए तीन टाइप में से किसी एक का इस्तेमाल करके पढ़ें. नीति सेट करने के लिए, आपके डिवाइस का मालिक DevicePolicyManager तरीके को कॉल करता है setSystemUpdatePolicy(). नीचे दिए गए कोड के सैंपल में, ऐसा करने का तरीका बताया गया है. विंडो वाली नीति का उदाहरण देखने के लिए, SystemUpdatePolicy दस्तावेज़ देखें.

// Create the system update policy to postpone installation for 30 days.
val policy = SystemUpdatePolicy.createPostponeInstallPolicy()

// Get a DevicePolicyManager instance to set the policy on the device.
val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE)
        as DevicePolicyManager
val adminName = getComponentName(context)

// Set the policy.
dpm.setSystemUpdatePolicy(adminName, policy)

// Create the system update policy to postpone installation for 30 days.
SystemUpdatePolicy policy = SystemUpdatePolicy.createPostponeInstallPolicy();

// Get a DevicePolicyManager instance to set the policy on the device.
DevicePolicyManager dpm = (DevicePolicyManager) context
    .getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminName = getComponentName(context);

// Set the policy.
dpm.setSystemUpdatePolicy(adminName, policy);

एक बार नीति इंस्टेंस बना लेने के बाद, उन्हें बदला नहीं जा सकता. डिवाइस पर अपडेट कब इंस्टॉल होंगे, यह तय करने के लिए नई नीति बनाई और सेट की जा सकती है. किसी नीति को डिवाइस, null पास करने वाले setSystemUpdatePolicy() को policy तर्क के रूप में कॉल करें. डीपीसी की ओर से किसी नीति को हटाने के बाद, डिवाइस इस्तेमाल करने वाले व्यक्ति को सिस्टम के लिए उपलब्ध सभी अपडेट की सूचनाएं दिखती हैं.

डिवाइस के लिए मौजूदा नीति जानने के लिए, ऐप्लिकेशन getSystemUpdatePolicy() को कॉल कर सकते हैं. अगर यह तरीका null दिखाता है, तो इसका मतलब है कि फ़िलहाल, नीति सेट नहीं है.

फ़्रीज़ किए गए पीरियड

छुट्टियों या व्यस्त समय के दौरान, ओएस वर्शन को फ़्रीज़ करने के लिए, डिवाइस के मालिक सिस्टम अपडेट को 90 दिनों तक निलंबित कर सकते हैं. जब कोई डिवाइस, फ़्रीज़ की अवधि के दौरान होता है, तो यह इस तरह काम करता है:

• डिवाइस पर, इंस्टॉल नहीं किए गए सिस्टम अपडेट के बारे में कोई सूचना नहीं मिलती.
• ओएस के सिस्टम अपडेट इंस्टॉल नहीं किए गए हैं.
• डिवाइस के उपयोगकर्ता, सेटिंग में जाकर मैन्युअल तरीके से सिस्टम अपडेट नहीं देख सकते.

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

अपडेट की गई नीति पर, फ़्रीज़ पीरियड सेट किया जाता है. नीति सेट किए बिना, फ़्रीज़ करने की अवधि सेट नहीं की जा सकती. जब डिवाइस आपके सेट किए गए किसी फ़्रीज़ पीरियड से बाहर होता है, तो नीति का सामान्य व्यवहार (ऑटोमैटिक, विंडो या टाला गया) लागू होता है.

फ़्रीज़ करने की अवधि सेट करने का तरीका

Android 9 (एपीआई लेवल 28) या उसके बाद के वर्शन में, फ़्रीज़ पीरियड को सेट किया जा सकता है. डिवाइस नीति सेट करने से पहले, मालिक सिस्टम अपडेट की नीति को फ़्रीज़ करने की अवधि सेट करता है डिवाइस के लिए. इसका तरीका यहां बताया गया है:

1. कोई नई सिस्टम अपडेट नीति बनाएं या मौजूदा नीति देखें.
2. setFreezePeriods() को कॉल करके, नीति पर फ़्रीज़ की अवधि सेट करें.
3. कॉल करके डिवाइस के लिए नीति और फ़्रीज़ करने की अवधि सेट करें setSystemUpdatePolicy().

फ़्रीज़ की अवधि हर साल दोहराई जाती है. इसलिए, अवधि के शुरू और खत्म होने की तारीखों को महीने और दिन की वैल्यू से दिखाया जाता है. फ़्रीज़ की पिछली अवधि खत्म होने के कम से कम 60 दिन बाद ही, फ़्रीज़ की नई अवधि शुरू की जा सकती है. यहां दिए गए उदाहरण में, किसी मौजूदा सिस्टम अपडेट नीति के लिए, फ़्रीज़ की दो अवधियां सेट करने का तरीका बताया गया है:

// Get the existing policy from the DevicePolicyController instance.
val policy = dpm.systemUpdatePolicy ?: return

try {
    // Set the two annual freeze periods on the policy for our retail
    // point-of-sale devices.
    val summerSale = FreezePeriod(
            MonthDay.of(6, 1),
            MonthDay.of(7, 31)) // Jun 1 - Jul 31 inclusive
    val winterSale = FreezePeriod(
            MonthDay.of(11, 20),
            MonthDay.of(1, 12)) // Nov 20 - Jan 12 inclusive
    policy.freezePeriods = Arrays.asList(summerSale, winterSale)

    // Set the policy again to activate the freeze periods.
    dpm.setSystemUpdatePolicy(adminName, policy)

} catch (e: SystemUpdatePolicy.ValidationFailedException) {
    // There must be previous periods recorded on the device because
    // summerSale and winterSale don’t overlap and are separated by more
    // than 60 days. Report the overlap ...
}

// Get the existing policy from the DevicePolicyController instance.
SystemUpdatePolicy policy = dpm.getSystemUpdatePolicy();

try {
  // Set the two annual freeze periods on the policy for our
  // retail point-of-sale devices.
  FreezePeriod summerSale = new FreezePeriod(
      MonthDay.of(6, 1),
      MonthDay.of(7, 31)); // Jun 1 - Jul 31 inclusive
  FreezePeriod winterSale = new FreezePeriod(
      MonthDay.of(11, 20),
      MonthDay.of(1, 12)); // Nov 20 - Jan 12 inclusive
  policy.setFreezePeriods(Arrays.asList(summerSale, winterSale));

  // Don’t forget to set the policy again to activate the freeze periods.
  dpm.setSystemUpdatePolicy(adminName, policy);

} catch (SystemUpdatePolicy.ValidationFailedException e) {
  // There must be previous periods recorded on the device because summerSale
  // and winterSale don’t overlap and are separated by more than 60 days.
  // Report the overlap ...
}

इसमें शुरू होने और खत्म होने की तारीखें शामिल हैं. अगर शुरू होने का दिन बड़ा है खत्म होने के दिन के बाद (जैसे कि पिछले उदाहरण में winterSale), फ़्रीज़ होने का समय अवधि अगले साल तक बढ़ा दी जाएगी.

फ़्रीज़ सेट करने पर के दौरान, Android इन शर्तों के लिए जांच करता है:

• खाते को 90 दिनों से ज़्यादा समय के लिए फ़्रीज़ नहीं किया जा सकता.
• खाते को फ़्रीज़ करने की अवधियों के बीच कम से कम 60 दिन का अंतर होना चाहिए.
• फ़्रीज़ करने की अवधियां ओवरलैप नहीं होनी चाहिए.
• कोई डुप्लीकेट फ़्रीज़ पीरियड नहीं हैं.

किसी डिवाइस के लिए सिस्टम अपडेट की नीति सेट करते समय, Android इन जांचों को दोहराता है और डिवाइस के लिए मौजूदा या पिछली फ़्रीज़ अवधियों को शामिल करता है.

इनमें से किसी भी टेस्ट के फ़ेल होने पर, Android SystemUpdatePolicy.ValidationFailedException दिखाता है.

सिस्टम अपडेट नीति ऑब्जेक्ट पर पहले से सेट किए गए फ़्रीज़ पीरियड की सूची पाने के लिए, सभी इंस्टॉल किए गए ऐप्लिकेशन SystemUpdatePolicy.getFreezePeriods() को कॉल कर सकते हैं. नीचे दिए गए उदाहरण के लिए, डिवाइस के फ़्रीज़ होने की अवधि को लॉग करने के लिए इस तरीके का इस्तेमाल किया जाता है:

// Log any freeze periods that might be set on a system update policy.
dpm.systemUpdatePolicy?.freezePeriods?.forEach {
    Log.i(TAG, "Freeze period: $it")
}

// Log any freeze periods that might be set on a system update policy.
SystemUpdatePolicy currentPolicy = dpm.getSystemUpdatePolicy();
if (currentPolicy != null) { // A policy might not be set.
  for (FreezePeriod freezePeriod : currentPolicy.getFreezePeriods()) {
    Log.i(TAG, "Freeze period: " + freezePeriod.toString());
  }
}

लीप ईयर

Android, फ़्रीज़ की अवधि का हिसाब लगाने के लिए, आईएसओ 8601 कैलेंडर (इसे ग्रिगोरियन कैलेंडर भी कहा जाता है) का इस्तेमाल करता है. यह लीप ईयर को अनदेखा करता है. इसका मतलब है कि 29 फ़रवरी को मान्य तारीख के तौर पर नहीं माना जाता. इसे 28 फ़रवरी के तौर पर माना जाता है. इसलिए, फ़्रीज़ (फ़्रीज़ होने की अवधि) की अवधि का हिसाब लगाते समय, 29 फ़रवरी को नहीं गिना जाता अवधि के लिए मान्य है.

डेवलपमेंट और टेस्टिंग

अपने DPC की सिस्टम अपडेट सुविधा को डेवलप और टेस्ट करते समय, कई फ़्रीज़ पीरियड की ज़रूरत होगी. Android, फ़्रीज़ करने की पिछली अवधियों के बीच 60 दिनों का अंतराल देखता है. इसलिए, हो सकता है कि पिछली अवधियों का रिकॉर्ड मिटाए बिना, फ़्रीज़ करने की नई अवधि सेट न की जा सके. डिवाइस का फ़्रीज़ होना हटाने के लिए पीरियड रिकॉर्ड को कॉपी करने के लिए, Android डीबग ब्रिज में यहां दिया गया कमांड चलाएं (adb) शेल:

adb shell dpm clear-freeze-period-record

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

Google Play के सिस्टम अपडेट (मेनलाइन)

Google Play के सिस्टम अपडेट (जिन्हें मेनलाइन अपडेट भी कहा जाता है) अपने-आप डाउनलोड हो जाते हैं. हालांकि, इन्हें इंस्टॉल करने के लिए डिवाइस को रीबूट करना ज़रूरी होता है. ये अपडेट, डिवाइस के अपने-आप रीबूट होने की सुविधा को ट्रिगर नहीं करेंगे. इसके बजाय, ये अपडेट डिवाइस के अगले उपयोगकर्ता, एडमिन या नीति के तहत रीबूट होने पर इंस्टॉल किए जाएंगे. सिस्टम अपडेट की नीति की वजह से रीबूट होने पर, उससे जुड़ा Google/OEM सिस्टम अपडेट और पहले से डाउनलोड किए गए Google Play के सिस्टम अपडेट इंस्टॉल हो जाएंगे.

Google Play के सिस्टम अपडेट, मैन्युअल तरीके से भी इंस्टॉल किए जा सकते हैं. ऐसा करने के लिए, इस पर जाएं सेटिंग > इसके बारे में > Android वर्शन > Google Play का सिस्टम अपडेट.

अपडेट को रोल बैक करना

कुछ मामलों में, Google Play के सिस्टम अपडेट को रोलबैक करने वाले टूल (GPSUR) का इस्तेमाल करके, डिवाइस की स्थिति को वापस लाया जा सकता है. ऐसा तब होता है, जब Google Play के सिस्टम अपडेट के इंस्टॉल होने में कोई समस्या आती है. इस टूल का इस्तेमाल, सिर्फ़ बेहतर उपयोगकर्ताओं को करना चाहिए. इसके अलावा, अगर सहायता टीम से ऐसा करने के लिए कहा जाए, तभी इसका इस्तेमाल करें. ऐसा करने पर, डेटा मिट सकता है. GPSUR टूल का इस्तेमाल करने का तरीका यहां बताया गया है:

1. अगर आपकी मशीन पर Android डीबग ब्रिज (adb) चल रहा है, तो आगे बढ़ने से पहले adb सेवा को बंद कर दें, ताकि यह रोलबैक प्रोसेस में रुकावट न डाले. adb को बंद करने के लिए, adb kill-server चलाएं.
2. जीपीएसयूआर टूल खोलें.
3. ADB ऐक्सेस करने की अनुमति दें पर क्लिक करके, टूल को adb के ज़रिए अपने टेस्ट डिवाइस से संपर्क करने की अनुमति दें.
4. नया डिवाइस जोड़ें पर क्लिक करें.
5. सूची में से अपना डिवाइस चुनें और कनेक्ट करें पर क्लिक करें. ऐसा हो सकता है कि इस सूची में डिवाइस का पूरा नाम शामिल होना चाहिए.
6. अपने डिवाइस की स्क्रीन पर, इस कंप्यूटर पर हमेशा अनुमति दें चुनें और क्लिक करें USB डीबगिंग कनेक्शन स्वीकार करने के लिए ठीक.
7. अपने ब्राउज़र में, कनेक्ट किया गया डिवाइस चुनें.
8. अगर आपके डिवाइस पर रोलबैक उपलब्ध हैं, तो पेज पर मौजूद बटन का टेक्स्ट, रोलबैक उपलब्ध नहीं हैं से बदलकर हाल ही के अपडेट रोलबैक करें पर स्विच हो जाना चाहिए. हाल ही के अपडेट को रोलबैक करें पर क्लिक करें.
9. रोलबैक की पुष्टि करें मॉडल पर चेतावनियां पढ़ें और पुष्टि करें पर क्लिक करें.
10. रोल बैक पूरा होने का इंतज़ार करें. इसके बाद, रोलबैक सफल मोडल दिखेगा और डिवाइस फिर चालू हो जाएगा. अब अपने डिवाइस को अनप्लग किया जा सकता है.

अन्य संसाधन

सिस्टम अपडेट के बारे में ज़्यादा जानने के लिए, Android ओपन सोर्स प्रोजेक्ट का OTA पढ़ें अपडेट से जुड़ा दस्तावेज़.