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

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

परिचय

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

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

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

टास्क डिवाइस का मालिक प्रोफ़ाइल स्वामी
उन सिस्टम अपडेट को देखना जिन्हें मंज़ूरी मिलना बाकी है
नए सिस्टम अपडेट उपलब्ध होने पर कॉलबैक पाना
Android के सिस्टम अपडेट कब इंस्टॉल हों, इसे कंट्रोल करने के लिए लोकल अपडेट की नीति सेट करें
ज़रूरी समय के दौरान, ओएस वर्शन को फ़्रीज़ करना

देखें कि क्या कोई अपडेट इंस्टॉल होना बाकी है

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

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

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

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

Kotlin

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

Java

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() पर कॉल करें कॉलबैक में सिस्टम अपडेट जोड़ते हैं. नीचे दिए गए उदाहरण में बताया गया है कि ऐसा कैसे किया जा सकता है:

Kotlin

/**
 * 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.
        // ...
    }
}

Java

/**
 * 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.
    // ...
  }
}

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

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

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

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

निलंबन की अवधि

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

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

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

नीति कैसे सेट करें

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

Kotlin

// 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)

Java

// 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 दिनों का ज़रूरी बफ़र पीरियड लागू करता है डिवाइस को अनिश्चित काल तक फ़्रीज़ होने से रोकने के लिए पीरियड. याद रखें, सिस्टम खुद ही फ़्रीज़ हो जाता है अपडेट, डिवाइसों को ज़रूरी अपडेट पाने से रोक सकते हैं.

पहली इमेज. किसी डिवाइस के लिए दो फ़्रीज़ पीरियड सेट किए गए
कैलेंडर में 60 दिन के बफ़र के साथ एक साल में दो फ़्रीज़ पीरियड दिखाए जा रहे हैं.

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

रोक लगने की अवधि कैसे सेट करें

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

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

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

Kotlin

// 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 ...
}

Java

// 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(). नीचे दिए गए उदाहरण के लिए, डिवाइस के फ़्रीज़ होने की अवधि को लॉग करने के लिए इस तरीके का इस्तेमाल किया जाता है:

Kotlin

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

Java

// 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, ISO 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 का सिस्टम अपडेट.

अन्य संसाधन

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