Systemupdates verwalten

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

Einführung

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

Mit Ihrem 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 Eigentümermodus ab

Nach ausstehenden Updates suchen

Ein ausstehendes Update ist ein Systemupdate für ein Gerät, das noch nicht installiert wurde. Der DPC kann IT-Administratoren dabei helfen, zu prüfen, auf welchen Geräten ausstehende Systemupdates verfügbar sind, und die Nutzer der Geräte gegebenenfalls auffordern, wichtige Updates umgehend zu installieren.

Geräte- und Profilinhaber mit Android 8.0 (API-Level 26) oder höher können prüfen, ob auf einem Gerät ein ausstehendes Systemupdate verfügbar ist. Rufe DevicePolicyManager.getPendingSystemUpdate() auf, was null zurückgibt, wenn das Gerät auf dem neuesten Stand ist. Wenn ein Systemupdate aussteht, gibt die Methode Informationen zum Update zurück.

Weitere Informationen zu einem ausstehenden Update

Nachdem Sie getPendingSystemUpdate() aufgerufen haben, können Sie den zurückgegebenen Wert SystemUpdateInfo prüfen, um mehr über das ausstehende Update zu erfahren. Im folgenden Beispiel wird gezeigt, wie Sie herausfinden können, wann ein ausstehendes Update zum ersten Mal für das Gerät verfügbar war:

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. Unter Android 8.0 oder höher werden auch die Profilinhaber benachrichtigt.

Überschreiben Sie in der Unterklasse DeviceAdminReceiver den Callback onSystemUpdatePending(). 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 des Updates. bevor Sie antworten. Unter getPendingSystemUpdate() erhalten Sie weitere Informationen zum 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. Die Richtlinie für Systemupdates kann einen von drei Typen haben:

Automatisch

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

Mit Fenster

Systemupdates werden während eines täglichen Wartungsfensters installiert (ohne Nutzerinteraktion). Legen Sie beim Erstellen einer neuen Richtlinie mit Zeitfenstern den Beginn und das Ende des täglichen Wartungsfensters in Minuten fest.

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. Nach 30 Tagen ohne neues Update fordert das System den Nutzer auf, 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. Wenn Sie angeben möchten, wann Systemupdates auf dem Gerät installiert werden sollen, erstellen Sie eine Instanz von SystemUpdatePolicy mit einem der drei oben beschriebenen Typen. 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 Fensterrichtlinie finden Sie in 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() aufrufen, um die aktuelle Richtlinie für das Gerät abzurufen. Wenn diese Methode null zurückgibt, ist derzeit keine Richtlinie festgelegt.

Zeiträume pausieren

Um die Betriebssystemversion über kritische Zeiten einzustellen, z. B. an Feiertagen oder anderen betriebsbedingten Zeiten erhalten, 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 zu ausstehenden Systemupdates.
• Systemupdates für das Betriebssystem werden nicht installiert.
• Gerätenutzer können in den Einstellungen nicht manuell nach Systemupdates suchen.

Das System erzwingt nach jeder Sperrung eine obligatorische 60-tägige Pufferzeit, um zu verhindern, dass das Gerät auf unbestimmte Zeit gesperrt wird. Denken Sie daran, dass das Einfrieren von Systemupdates verhindern kann, dass Geräte wichtige Updates erhalten.

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 Zeiträume befindet, gilt das normale Richtlinienverhalten (automatisch, Wartungsfenster oder Verschieben).

Sperrzeit festlegen

Sie können Zeiträume für die Sperrung unter Android 9 (API-Level 28) oder höher festlegen. Ein Geräteeigentümer legt eine Sperrfrist für eine Systemupdate-Richtlinie fest, bevor er die Richtlinie für das Gerät festlegt. Gehen Sie dazu so vor:

1. Erstellen Sie eine neue Systemaktualisierungsrichtlinie oder rufen Sie die aktuelle 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 Sperrfrist jährlich wiederholt, werden die Start- und Enddaten der Sperrfrist durch Monats- und Tageswerte dargestellt. Der Starttag muss mindestens 60 Tage nach dem Ende einer vorherigen Sperrfrist beginnen. 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 inbegriffen. Wenn der Starttag länger ist als am Ende des Tages (wie winterSale im vorherigen Beispiel), bis zum nächsten Jahr.

Wenn Sie für eine Systemupdate-Richtlinie eine Sperrzeit festlegen, prüft Android, ob die folgenden Anforderungen erfüllt sind:

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

Wenn Sie die Richtlinie für Systemupdates für ein Gerät festlegen, wiederholt Android diese Tests und berücksichtigt alle aktuellen oder vergangenen Zeiträume, in denen das Gerät eingefroren war.

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

Um eine Liste der zuvor für ein Objekt mit Systemupdaterichtlinien festgelegten Sperrzeiträume abzurufen, können alle installierten Apps SystemUpdatePolicy.getFreezePeriods() aufrufen. Im folgenden Beispiel wird diese Methode aufgerufen, um die Zeiträume zu protokollieren, in denen ein Gerät eingefroren ist:

// 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 nicht als gültiges Datum erkannt und als 28. Februar behandelt wird. Daher wird der 29. Februar bei der Berechnung der Dauer einer Sperrfrist nicht gezählt.

Entwicklung und Tests

Während Sie die Systemupdatefunktion Ihrer DPC entwickeln und testen, müssen Sie möglicherweise viele Zeiträume für die Sperrung festlegen. Da Android zwischen den bisherigen Ruhezeiträumen ein Intervall von 60 Tagen prüft, können Sie möglicherweise keine neue Ruhezeit festlegen, ohne zuerst den Eintrag der bisherigen Zeiträume 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) 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, einen Administrator oder eine Richtlinie ausgelöst wird. Vom System ausgelöste Neustarts das zugehörige Google/OEM-Systemupdate und alle heruntergeladene Google Play-Systemupdates.

Google Play-Systemupdates können auch manuell installiert werden. Rufen Sie dazu Einstellungen > Info > Android-Version > Google Play-Systemupdate auf.

Rollback für ein Update ausführen

In einigen Fällen kann das Tool „Google Play System Update Rollbacks“ (GPSUR) verwendet werden, um den Gerätestatus nach einer problematischen Installation eines Google Play-Systemupdates wiederherzustellen. Dieses Tool sollte von fortgeschrittenen Nutzern verwendet werden oder wenn sie dazu aufgefordert werden. da dies zu Datenverlusten führen kann. So verwenden Sie das GPSUR-Tool:

1. Wenn Android Debug Bridge (adb) auf Ihrem Computer ausgeführt wird, beenden Sie den adb-Dienst, bevor Sie fortfahren, damit er den Rollback-Vorgang nicht beeinträchtigt. Führen Sie adb kill-server aus, um ADB zu beenden.
2. Öffnen Sie das GPSUR-Tool.
3. Klicken Sie auf Allow ADB access (ADB-Zugriff zulassen), damit das Tool mit Ihrem Test kommunizieren kann. über ADB.
4. Klicken Sie auf Neues Gerät hinzufügen.
5. Wählen Sie Ihr Gerät aus der Liste aus und klicken Sie auf Verbinden. Diese Liste enthält möglicherweise nicht den vollständigen Gerätenamen.
6. Wählen Sie auf dem Display Ihres Geräts Von diesem Computer immer zulassen aus und klicken Sie auf OK, um die USB-Debugging-Verbindung zu akzeptieren.
7. Wählen Sie in Ihrem Browser das verbundene Gerät aus.
8. Wenn auf Ihrem Gerät Rollbacks verfügbar sind, sollte der Text auf der Seite von Keine Rollbacks verfügbar zu Rollback der letzten Updates wechseln. Klicken Sie auf Rollback der letzten Updates durchführen.
9. Lesen Sie die Warnungen im modalen Dialogfeld Rollback bestätigen und klicken Sie auf Bestätigen.
10. Warten Sie, bis das Rollback abgeschlossen ist. Anschließend wird das Modalfenster Rollback erfolgreich angezeigt und das Gerät wird neu gestartet. Sie können das Gerät jetzt vom Stromnetz trennen.

Weitere Informationen

Weitere Informationen zu Systemupdates finden Sie in der Dokumentation zu Over-the-air-Updates des Android Open Source Project.