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). In Tabelle 1 wird gezeigt, wie Geräteinhaber Systemupdates 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. 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. 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 über die Aktualisierung zurück.

Weitere Informationen zu ausstehenden Updates

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 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. Es gibt drei Arten von Richtlinien für Systemupdates:

Automatisch

Systemupdates werden installiert, sobald sie (ohne Nutzerinteraktion) verfügbar. Wenn Sie diesen Richtlinientyp festlegen, werden alle ausstehenden Updates sofort installiert, die möglicherweise verschoben wurden 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. Der Zeitraum beginnt, wenn das System das Update zum ersten Mal verschiebt. Das Festlegen neuer Richtlinien für die Verschiebung verlängert den Zeitraum nicht.

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. Wenn später ein neues Systemupdate verfügbar ist, beginnt der 30-tägige Zeitraum noch einmal.

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. Wenn Sie ändern möchten, wann auf einem Gerät Updates installiert werden, können Sie eine neue Richtlinie erstellen und festlegen. Wenn Sie eine Richtlinie von einem Gerät entfernen möchten, rufen Sie setSystemUpdatePolicy() auf und übergeben Sie null als policy-Argument. Nachdem Ihr DPC eine Richtlinie entfernt hat, erhält der Gerätenutzer Benachrichtigungen zu 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.

Zeiträume pausieren

Wenn Sie die Betriebssystemversion in kritischen Zeiträumen wie Feiertagen oder anderen geschäftigen Zeiten einfrieren möchten, können Geräteeigentümer Systemupdates für bis zu 90 Tage pausieren. Wenn ein sich innerhalb einer Sperrzeit befindet, verhält es sich so:

• Das Gerät erhält keine Benachrichtigungen zu ausstehenden 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 nach jeder definierten Sperrung einen obligatorischen 60-tägigen Pufferzeitraum. 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.

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

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 Ende des Tages (wie winterSale im vorherigen Beispiel), 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.

Beim Festlegen der Richtlinie für Systemupdates für ein Gerät 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.

Um eine Liste der zuvor für ein Objekt mit Systemupdaterichtlinien festgelegten Sperrzeiträume abzurufen, können alle installierten Apps SystemUpdatePolicy.getFreezePeriods() aufrufen. Die folgenden Im Beispiel wird die folgende Methode aufgerufen, um die Aufbewahrungszeiträume 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. Sie werden stattdessen beim nächsten Neustart installiert, der von einem Nutzer, Administrator oder einer Richtlinie initiiert 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.

Rollback einer Aktualisierung durchfü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 den GPSUR-Algorithmus Tool:

1. Wenn auf Ihrem Computer Android Debug Bridge (ADB) ausgeführt wird, beenden Sie bevor Sie fortfahren, damit der ADB-Dienst nicht einen Rollback-Prozess. 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 den vollständigen Gerätenamen enthalten.
6. Wählen Sie auf dem Bildschirm Ihres Geräts die Option Auf 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. Der Schaltflächentext auf der Seite sollte von Keine Rollbacks verfügbar zu Führen Sie ein Rollback für die letzten Updates durch, sofern auf Ihrem Gerät Rollbacks verfügbar sind. Klicken Sie auf Rollback der letzten Updates durchführen.
9. Lesen Sie die Warnungen im modalen Rollback bestätigen und klicken Sie auf Bestätigen.
10. Warten Sie, bis das Rollback abgeschlossen ist. Nach Abschluss ist ein Rollback erfolgreich wird angezeigt und das Gerät wird neu gestartet. Sie können das .

Weitere Informationen

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