Systemupdates verwalten

In diesem Entwicklerhandbuch wird erläutert, wie Sie mit Ihrem Device Policy Controller (DPC) Android-Systemupdates im Namen des Gerätenutzers verwalten

Einführung

Android-Geräte können OTA-Updates (Over The Air) empfangen und auf dem System installieren und Anwendungssoftware. Android benachrichtigt den Gerätenutzer, dass ein Systemupdate ist verfügbar und der Gerätenutzer kann das Update sofort oder später installieren.

Über Ihren DPC kann ein IT-Administrator Systemupdates für den Gerätenutzer verwalten. DPCs können ein vollständig verwaltetes Gerät (Geräteinhaber genannt) oder Inhaber eines Arbeitsprofils sein (Profilinhaber genannt). Tabelle 1 zeigt, wie Geräteeigentümer das System verwalten können während Profilinhaber nur Informationen zu Systemupdates melden können.

Tabelle 1: Für DPCs verfügbare Aufgaben hängen vom Inhabermodus ab.

Nach ausstehenden Updates suchen

Ein ausstehendes Update ist ein Systemupdate für ein Gerät, das noch nicht installiert wurde. Ihr DPC kann IT-Administratoren dabei unterstützen, zu prüfen, für welche Geräte Systemupdates ausstehen. Gerätenutzer könnten Sie bitten, wichtige Updates umgehend zu installieren.

Geräte- und Profilinhaber mit Android 8.0 (API-Level 26) oder höher kann prüfen, ob für ein Gerät ein Systemupdate aussteht. Anruf DevicePolicyManager.getPendingSystemUpdate() gibt null zurück, wenn das Gerät auf dem neuesten Stand ist. Wenn ein Systemupdate aussteht, gibt die Methode Informationen über die Aktualisierung zurück.

Weitere Informationen zu einem ausstehenden Update

Nach dem Aufrufen von getPendingSystemUpdate() können Sie die zurückgegebene SystemUpdateInfo, um mehr über das ausstehende Update zu erfahren. Die Das folgende Beispiel zeigt, wie Sie herausfinden könnten, wann ein ausstehendes Update zum ersten Mal für das Gerät verfügbar:

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

System-Callbacks

Wenn ein Update verfügbar ist, werden die Geräteeigentümer über das Android-System zum neuen Update. Ab Android 8.0 werden auch die Profilinhaber benachrichtigt.

Überschreiben Sie in der abgeleiteten DeviceAdminReceiver-Klasse den onSystemUpdatePending()-Rückruf. Sie benötigen keine um Ihren DPC zu registrieren oder für den Empfang des Callbacks zu werben. Das System kann rufen Sie diese Methode für ein einzelnes Update mehrmals auf. Prüfen Sie daher den Status bevor Sie antworten. Rufen Sie unter getPendingSystemUpdate() an, um mehr zu erfahren Systemupdate im Callback. Das folgende Beispiel zeigt, wie das geht:

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

Wenn ein System mehr als einen DPC hat, z. B. Arbeitsprofile auf vollständig verwalteten Geräten erhalten sowohl der Geräteeigentümer als auch der Profilinhaber den Rückruf.

Richtlinien aktualisieren

Ein Geräteeigentümer kann durch Festlegen eines lokalen Systems steuern, wann Updates installiert werden für ein Gerät aktualisieren. Es gibt drei Arten von Richtlinien für Systemupdates:

Automatisch

Systemupdates werden installiert, sobald sie (ohne Nutzerinteraktion) verfügbar. Wenn du diesen Richtlinientyp festlegst, werden alle ausstehenden Updates sofort installiert die möglicherweise verschoben werden oder auf ein Wartungsfenster warten.

Mit Fenster

Installiert Systemupdates im Rahmen einer täglichen Wartung -Fenster (ohne Nutzerinteraktion). Legen Sie den Beginn und das Ende des täglichen Wartungsfensters in Minuten am Tag, wenn eine neue Richtlinie im Fenstermodus erstellt wird.

Verschoben

Die Installation von Systemupdates wird um 30 Tage verschoben. Nach den 30 Tagen abgelaufen ist, fordert das System den Gerätenutzer auf, das Update zu installieren.

Verschiebungszeiträume

Jedes Update wird vom System auf eine Verschiebung um 30 Tage beschränkt. Die Periode beginnt, wenn erst später im System. Wenn Sie neue Richtlinien für die Verschiebung festlegen, den Zeitraum zu verlängern.

Abgesehen von der Verschiebung kann Android möglicherweise keine Updates für andere Gründe wie fehlende Konnektivität, unzureichender Speicherplatz oder ein niedriger Akkustand.

Das System setzt den Timer für die 30-tägige Verschiebung zurück, wenn ein anderes Update während des gesamten Zeitraums verfügbar, sodass IT-Administratoren die Möglichkeit haben, das kombinierte System Aktualisierungen. Wenn 30 Tage lang keine neue Aktualisierung durchgeführt wurde, werden Sie vom System aufgefordert, um alle ausstehenden Updates zu installieren. Später, wenn ein neues Systemupdate beginnt der 30-Tage-Zeitraum erneut.

Richtlinie festlegen

Updaterichtlinien können ab Android 8.0 (API-Level 26) festgelegt werden. Zum Angeben wann Systemupdates auf dem Gerät installiert werden sollen, erstellen Sie eine Instanz von SystemUpdatePolicy mit einem der drei oben genannten Typen oben. Zum Festlegen einer Richtlinie ruft der Geräteeigentümer die Methode DevicePolicyManager auf setSystemUpdatePolicy() Der folgende Code Beispiel zeigt, wie Sie das erreichen können. Ein Beispiel für eine Richtlinie im Fenstermodus finden Sie der SystemUpdatePolicy-Dokumentation.

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

Richtlinieninstanzen können nach dem Erstellen nicht mehr geändert werden. Um zu ändern, wann ein Gerät installiert haben, können Sie eine neue Richtlinie erstellen und festlegen. Um eine Richtlinie aus einer Gerät auf, rufen Sie setSystemUpdatePolicy() auf und übergeben Sie null als policy-Argument. Nachdem Ihr DPC eine Richtlinie entfernt hat, sieht der Gerätenutzer Benachrichtigungen für alle verfügbaren Systemupdates.

Apps können getSystemUpdatePolicy() anrufen, um die aktuelle Richtlinie für das Gerät. Wenn diese Methode null zurückgibt, bedeutet dies, dass Richtlinie derzeit nicht festgelegt ist.

Aufbewahrungszeiträume

Um die Betriebssystemversion über kritische Zeiten einzustellen, z. B. an Feiertagen oder anderen betriebsbedingten Zeiten können Geräteeigentümer Systemupdates bis zu 90 Tage lang aussetzen. Wenn ein sich innerhalb einer Sperrzeit befindet, verhält es sich so:

• Das Gerät erhält keine Benachrichtigungen über ausstehende Systemupdates.
• Es sind keine Systemupdates für das Betriebssystem installiert.
• Gerätenutzer können in den Einstellungen nicht manuell nach Systemupdates suchen.

Das System erzwingt einen obligatorischen 60-tägigen Pufferzeitraum nach jeder definierten Sperrung. um zu verhindern, dass das Gerät auf unbestimmte Zeit eingefroren wird. Denken Sie daran, das Einfrieren Updates können verhindern, dass Geräte wichtige Updates erhalten.

</ph>

Sie legen Zeiträume für Update-Richtlinien fest. Sie können Sperrzeiträume nur einrichten, das Festlegen einer Richtlinie. Wenn sich das Gerät außerhalb der von Ihnen festgelegten Sperrzeiträume befindet, gilt Folgendes: gilt das normale Richtlinienverhalten (automatisch, im Fenstermodus oder verschoben).

Zeitraum für die Sperre festlegen

Zeiträume lassen sich unter Android 9 (API-Level 28) oder höher festlegen. Ein Gerät Der Inhaber legt eine Sperrzeit für eine Richtlinie für Systemupdates fest, bevor er sie festlegt für das Gerät. Dazu sind folgende Schritte erforderlich:

1. Erstellen Sie eine neue Richtlinie für Systemupdates oder rufen Sie die aktuelle Richtlinie ab.
2. Legen Sie die Zeiträume für die Richtlinie fest, indem Sie folgenden Befehl aufrufen: setFreezePeriods()
3. Legen Sie die Richtlinien und Sperrzeiträume für das Gerät fest, indem Sie folgenden Befehl aufrufen: setSystemUpdatePolicy()

Da sich die Sperrzeit jährlich wiederholt, werden das Start- und Enddatum der Zeitraum werden durch Monats- und Tageswerte dargestellt. Der Starttag muss mit mindestens 60 Tage nach dem Ende der vorherigen Sperrzeit. Im folgenden Beispiel zeigt, wie Sie zwei Sperrzeiträume für eine vorhandene Richtlinie für Systemupdates festlegen können:

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

Sowohl der Start- als auch der Endtag sind eingeschlossen. Wenn der Starttag länger ist als am Endtag (wie winterSale im vorherigen Beispiel), das Freezes bis zum nächsten Jahr.

Beim Festlegen der Fixierung festgelegten Zeiträumen, testet Android diese Anforderungen:

• Die Sperrzeit darf nicht länger als 90 Tage sein.
• Das Intervall zwischen den Zeiträumen beträgt mindestens 60 Tage.
• Die Zeiträume überschneiden sich nicht.
• Es gibt keine doppelten Sperrzeiträume.

Wenn die Richtlinie für Systemupdates für ein Gerät festgelegt wird, wiederholt Android diese Tests und umfasst alle aktuellen oder vergangenen Sperrzeiten für das Gerät.

Android löst SystemUpdatePolicy.ValidationFailedException aus, wenn einer dieser Tests fehlschlägt.

So rufen Sie eine Liste der Zeiträume auf, die zuvor für ein Richtlinienobjekt für Systemupdates festgelegt wurden: können alle installierten Apps anrufen SystemUpdatePolicy.getFreezePeriods() Die folgenden Im Beispiel wird diese Methode aufgerufen, um die Zeiträume für die Fixierung eines Geräts zu protokollieren:

// 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());
  }
}

Schaltjahre

In Android wird der ISO 8601-Kalender (auch Gregorianische Kalender genannt) verwendet, Schaltjahre werden ignoriert. Das bedeutet, dass der 29. Februar wird nicht als gültiges Datum erkannt und so behandelt, als wäre es der 28. Februar. Daher wird der 29. Februar bei der Berechnung der Dauer einer Aussetzung nicht berücksichtigt. Punkt.

Entwicklung und Tests

Während Sie die Funktion zur Systemaktualisierung Ihres DPC entwickeln und testen, mehrere Zeiträume erstellen müssen. Weil Android nach 60 Tagen sucht zwischen vergangenen Sperrzeiträumen liegt, können Sie möglicherweise keine neue Sperrzeit festlegen. ohne zuvor den Datensatz der vergangenen Perioden zu löschen. So löschen Sie die Fixierung des Geräts: Führen Sie den folgenden Befehl in Android Debug Bridge aus. (adb)-Shell:

adb shell dpm clear-freeze-period-record

Sie können feststellen, ob ein Gerät in der Sperrzeit ist, indem Sie prüfen, ob der Nutzer ist für Systemupdates deaktiviert.

Google Play-Systemupdates (Mainline)

Google Play-Systemupdates (auch Mainline-Updates genannt) sind werden automatisch heruntergeladen. Zur Installation ist jedoch ein Neustart des Geräts erforderlich. Diese Updates lösen keinen automatischen Neustart aus, sondern werden der nächste Neustart durch einen Nutzer, Administrator oder eine Richtlinie ausgelöst wird. Vom System ausgelöste Neustarts das zugehörige Google/OEM-Systemupdate und alle heruntergeladene Google Play-Systemupdates.

Sie können Google Play-Systemupdates auch manuell installieren. Gehen Sie dazu zu Einstellungen > Über > Android-Version > Google Play-Systemupdate.

Weitere Informationen

Weitere Informationen zu Systemupdates finden Sie auf der OTA-Website des Android Open Source Project (OTA). Updates.