Gerät registrieren und bereitstellen

Bei der Bereitstellung wird ein Gerät so eingerichtet, dass es von einem enterprise über policies verwaltet werden kann. Während des Vorgangs wird auf dem Gerät die Android Device Policy App installiert, die zum Empfangen und Durchsetzen von policies verwendet wird. Wenn die Bereitstellung erfolgreich ist, erstellt die API ein devices-Objekt, das das Gerät an ein Unternehmen bindet.

Die Android Management API verwendet Registrierungstokens, um den Bereitstellungsprozess auszulösen. Das Registrierungstoken und die Bereitstellungsmethode, die Sie verwenden, bestimmen die Eigentümerschaft eines Geräts (privat oder unternehmenseigen) und den Verwaltungsmodus (Arbeitsprofil oder vollständig verwaltetes Gerät).

Ein Kontingentsystem steuert, wie viele Geräte pro Projekt verwaltet werden können. Sie müssen ein anfängliches Gerätekontingent anfordern, bevor Sie Ihr erstes Gerät bereitstellen können.

Private Geräte

Android 5.1 oder höher

Geräte, die Mitarbeitern gehören, können mit einem Arbeitsprofil eingerichtet werden. Ein Arbeitsprofil bietet einen eigenständigen Bereich für geschäftliche Apps und Daten, der von privaten Apps und Daten getrennt ist. Die meisten policies für die Verwaltung von Apps, Daten und anderen Elementen gelten nur für das Arbeitsprofil, während die privaten Apps und Daten des Mitarbeiters privat bleiben.

Wenn Sie ein Arbeitsprofil auf einem privaten Gerät einrichten möchten, erstellen Sie ein Registrierungstoken (achten Sie darauf, dass allowPersonalUsage auf PERSONAL_USAGE_ALLOWED festgelegt ist) und verwenden Sie eine der folgenden Bereitstellungsmethoden:

• Arbeitsprofil über die Einstellungen hinzufügen
• Android Device Policy herunterladen
• Link zum Registrierungstoken
• Anmelde-URL

Unternehmenseigene Geräte für die geschäftliche und private Nutzung

Android 8 oder höher

Wenn Sie ein unternehmenseigenes Gerät mit einem Arbeitsprofil einrichten, kann es sowohl für geschäftliche als auch für private Zwecke verwendet werden. Auf unternehmenseigenen Geräten mit Arbeitsprofilen:

• Die meisten policies für die Verwaltung von Apps, Daten und anderen Elementen gelten nur für das Arbeitsprofil.
• Das private Profil des Mitarbeiters bleibt privat. Unternehmen können jedoch bestimmte geräteübergreifende Richtlinien und Richtlinien für die private Nutzung erzwingen.
• Unternehmen können blockScope verwenden, um Compliance-Maßnahmen auf einem gesamten Gerät oder nur auf dem Arbeitsprofil zu erzwingen.
• devices.delete und Gerätebefehle gelten für ein gesamtes Gerät.

Wenn Sie ein unternehmenseigenes Gerät mit einem Arbeitsprofil einrichten möchten, erstellen Sie ein Registrierungstoken (achten Sie darauf, dass allowPersonalUsage auf PERSONAL_USAGE_ALLOWED festgelegt ist) und verwenden Sie eine der folgenden Bereitstellungsmethoden:

• Zero-Touch-Registrierung
• QR-Code
• Anmelde-URL
• DPC-Kennung

Unternehmenseigene Geräte nur für die geschäftliche Nutzung

Android 5.1 oder höher

Die vollständige Geräteverwaltung eignet sich für unternehmenseigene Geräte, die ausschließlich für die Arbeit verwendet werden. Unternehmen können alle Apps auf dem Gerät verwalten und alle Richtlinien und Befehle der Android Management API erzwingen.

Es ist auch möglich, ein Gerät per Richtlinie auf eine einzelne App oder eine kleine Gruppe von Apps zu beschränken, um einen bestimmten Zweck oder Anwendungsfall zu erfüllen. Diese Teilmenge vollständig verwalteter Geräte wird als zweckbestimmte Geräte bezeichnet. Bei Registrierungstokens für diese Geräte muss allowPersonalUsage auf PERSONAL_USAGE_DISALLOWED_USERLESS festgelegt sein.

Wenn Sie die vollständige Verwaltung auf einem unternehmenseigenen Gerät einrichten möchten, erstellen Sie ein Registrierungstoken. Achten Sie darauf, dass allowPersonalUsage auf PERSONAL_USAGE_DISALLOWED oder PERSONAL_USAGE_DISALLOWED_USERLESS festgelegt ist, und verwenden Sie eine der folgenden Bereitstellungsmethoden.

• Zero-Touch-Registrierung
• QR-Code
• Anmelde-URL (nicht für zweckbestimmte Geräte geeignet)
• NFC
• DPC-Kennung

Richtlinien können sich auf die Generierung der Benutzeroberfläche während der Gerätebereitstellung auswirken. Diese Richtlinien sind:

• PasswordPolicyScope: Damit werden die Passwortanforderungen festgelegt.
• PermittedInputMethods: Damit werden die Eingabemethoden für das Paket festgelegt.
• PermittedAccessibilityServices: Damit wird festgelegt, welche Bedienungshilfen für vollständig verwaltete Geräte und Arbeitsprofile zulässig sind.
• SetupActions: Damit wird festgelegt, welche Aktionen während der Einrichtung ausgeführt werden.
• ApplicationsPolicy: Damit wird die Richtlinie für eine einzelne App festgelegt.

Wenn Sie möchten, dass während der Gerätebereitstellung neben der Installation von geschäftlichen Apps und Geräteregistrierungskarten auch Schritte zur Passworteingabe angezeigt werden, empfehlen wir, Ihre Richtlinien so zu aktualisieren, dass die Initiierung der UI-Generierung verzögert wird. Dazu müssen Sie das Gerät in einem Quarantänestatus belassen, der auftritt, wenn es ohne eine zugehörige Richtlinie registriert wird, bis Sie die endgültige Richtlinie für die Geräteeinrichtung mit den für Ihre Einrichtungsanforderungen relevanten Elementen angeben. Nachdem die Bereitstellung des Geräts abgeschlossen ist, können Sie die Richtlinie nach Bedarf ändern.

Registrierungstoken erstellen

Sie benötigen ein Registrierungstoken für jedes Gerät, das Sie registrieren möchten. Sie können dasselbe Token für mehrere Geräte verwenden. Rufen Sie enterprises.enrollmentTokens.create auf, um ein Registrierungstoken anzufordern. Registrierungstokens laufen standardmäßig nach einer Stunde ab. Sie können jedoch eine benutzerdefinierte Ablaufzeit (duration) von bis zu etwa 10.000 Jahren angeben.

Bei einer erfolgreichen Anfrage wird ein enrollmentToken-Objekt mit einer enrollmentTokenId und einer qrcode zurückgegeben, die IT-Administratoren und Endnutzer zum Bereitstellen von Geräten verwenden können.

Richtlinie angeben

Sie können auch eine policyName in der Anfrage angeben, um eine Richtlinie gleichzeitig mit der Registrierung eines Geräts anzuwenden. Wenn Sie keinen policyName angeben, lesen Sie den Abschnitt Gerät ohne Richtlinie registrieren.

Private Nutzung angeben

allowPersonalUsage bestimmt, ob dem Gerät während der Bereitstellung ein Arbeitsprofil hinzugefügt werden kann. Legen Sie PERSONAL_USAGE_ALLOWED fest, damit ein Nutzer ein Arbeitsprofil erstellen kann (erforderlich für private Geräte, optional für unternehmenseigene Geräte).

Ausnahme für vorhandene Registrierungstokens

Einige Kunden verwenden Registrierungstokens mit langen Ablaufdaten, um wiederholte Registrierungen durchzuführen. Damit diese bestehenden Workflows nicht unterbrochen werden, sind alle Tokens, die VOR der erstmaligen Aktivierung der Anforderung „Mit Google authentifizieren“ erstellt wurden, von den neuen Anmeldeaufforderungen ausgenommen. Diese älteren Tokens funktionieren weiterhin wie zuvor. Nutzer können damit Geräte registrieren, ohne den Google-Authentifizierungsprozess durchlaufen zu müssen.

Alle Tokens, die erstellt wurden, NACHDEM die Google-Authentifizierungsanforderung zum ersten Mal aktiviert wurde, unterliegen jedoch den neuen Authentifizierungsregeln. Das bedeutet, dass Nutzer sich auf Geräten, die diese neueren Tokens verwenden, gemäß den vom IT-Administrator ausgewählten Einstellungen authentifizieren müssen. Bei zweckbestimmten Geräten, auf denen keine Nutzerdaten gespeichert werden sollen, muss allowPersonalUsage auf PERSONAL_USAGE_DISALLOWED_USERLESS festgelegt sein, damit der Authentifizierungsbildschirm nicht angezeigt wird.

Google-Authentifizierung bei der Registrierung erzwingen

EMMs können die Anmeldung im Google-Konto während der Geräteregistrierung erzwingen, indem sie die entsprechenden Werte für das Registrierungs- oder Anmeldetoken festlegen. Diese Konfiguration bestimmt, ob die Schaltfläche „Überspringen“ auf dem Google-Anmeldebildschirm ausgeblendet wird. Wenn diese Optionen festgelegt sind, überschreiben sie die unternehmensweite googleAuthenticationSettings-Richtlinie.

Konfigurationsoptionen

Sie können das Authentifizierungsverhalten mit dem Objekt „googleAuthenticationOptions“ in einem EnrollmentToken oder einem SigninDetail steuern.

Beispiele für JSON-Nutzlasten

Schaltfläche „Überspringen“ deaktivieren

Wenn Sie die Schaltfläche „Überspringen“ ausblenden und den Nutzer zwingen möchten, sich mit einem gültigen Arbeitskonto anzumelden, legen Sie die Authentifizierungsanforderung auf ERFORDERLICH fest.

{
  ...
  "googleAuthenticationOptions": {
    "authenticationRequirement": "REQUIRED"
  }
}

Bestimmte Konto-E-Mail-Adresse erforderlich

Wenn Sie den Nutzer zwingen möchten, sich mit einem bestimmten Konto anzumelden, definieren Sie den String requiredAccountEmail. Die Anfrage zur Token-Erstellung schlägt mit dem Fehler INVALID_ARGUMENT fehl, wenn das Feld „requirement“ nicht auf REQUIRED gesetzt ist.

{
...
  "googleAuthenticationOptions": {
    "authenticationRequirement": "REQUIRED",
    "requiredAccountEmail": "user@enterprise.com"
  }
}

QR-Codes

QR-Codes sind eine effiziente Methode zur Gerätebereitstellung für Unternehmen, die viele verschiedene Richtlinien verwalten. Der von enterprises.enrollmentTokens.create zurückgegebene QR-Code besteht aus einer Nutzlast von Schlüssel/Wert-Paaren, die ein Registrierungstoken und alle Informationen enthalten, die für die Bereitstellung eines Geräts durch Android Geräterichtlinien erforderlich sind.

Beispiel für ein QR-Code-Bundle

Das Bundle enthält den Download-Speicherort von Android-Geräterichtlinien und ein Registrierungstoken.

{
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup",
    "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
        "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "{enrollment-token}"
    }
}

Sie können den von enterprises.enrollmentTokens.create zurückgegebenen QR-Code direkt verwenden oder anpassen. Eine vollständige Liste der Attribute, die Sie in ein QR-Code-Bundle aufnehmen können, finden Sie unter QR-Code erstellen.

Wenn Sie den String qrcode in einen scannbaren QR-Code umwandeln möchten, verwenden Sie einen QR-Code-Generator wie ZXing.

Bereitstellungsmethoden

In diesem Abschnitt werden verschiedene Methoden zur Bereitstellung eines Geräts beschrieben.

Arbeitsprofil über die Einstellungen hinzufügen

Android 5.1 oder höher

Nutzer haben folgende Möglichkeiten, ein Arbeitsprofil auf ihrem Gerät einzurichten:

1. Gehe zu den Einstellungen > Google > Einrichten und wiederherstellen.
2. Tippen Sie auf Arbeitsprofil einrichten.

Mit diesen Schritten wird ein Einrichtungsassistent gestartet, der die Android-Geräterichtlinien auf das Gerät herunterlädt. Als Nächstes wird der Nutzer aufgefordert, einen QR-Code zu scannen oder manuell ein Registrierungstoken einzugeben, um die Einrichtung des Arbeitsprofils abzuschließen.

Android Device Policy herunterladen

Android 5.1 oder höher

Um ein Arbeitsprofil auf ihrem Gerät einzurichten, können Nutzer die Android Device Policy aus dem Google Play Store herunterladen. Nach der Installation der App wird der Nutzer aufgefordert, einen QR-Code zu scannen oder ein Registrierungstoken manuell einzugeben, um die Einrichtung des Arbeitsprofils abzuschließen.

Link zum Registrierungstoken

Android 5.1 oder höher

Generieren Sie mit dem von enrollmentTokens.create zurückgegebenen Registrierungstoken oder der signinEnrollmentToken des Unternehmens eine URL im folgenden Format:

https://enterprise.google.com/android/enroll?et=<enrollmentToken>

Sie können diese URL an IT-Administratoren weitergeben, die sie dann ihren Endnutzern zur Verfügung stellen können. Wenn ein Endnutzer den Link auf seinem Gerät öffnet, wird er durch die Einrichtung des Arbeitsprofils geführt.

Anmelde-URL

Bei dieser Methode werden Nutzer auf eine Seite weitergeleitet, auf der sie alle zusätzlichen Informationen eingeben können, die für die Bereitstellung erforderlich sind. Anhand der vom Nutzer eingegebenen Informationen können Sie die entsprechende Richtlinie für den Nutzer berechnen, bevor Sie mit der Gerätebereitstellung fortfahren. Beispiel:

1. Geben Sie Ihre Anmelde-URL in enterprises.signInDetails[] an. Legen Sie allowPersonalUsage auf PERSONAL_USAGE_ALLOWED fest, wenn Sie einem Nutzer erlauben möchten, ein Arbeitsprofil zu erstellen (erforderlich für private Geräte, optional für unternehmenseigene Geräte).

   Fügen Sie den resultierenden signinEnrollmentToken als Bereitstellungs-Extra zu einem QR-Code, einer NFC-Nutzlast oder einer Zero-Touch-Konfiguration hinzu. Alternativ können Sie den Nutzern die signinEnrollmentToken direkt zur Verfügung stellen.

2. Wählen Sie eine Option aus:

   1. Unternehmenseigene Geräte: Nachdem Sie ein neues oder auf die Werkseinstellungen zurückgesetztes Gerät eingeschaltet haben, übertragen Sie das signinEnrollmentToken auf das Gerät (per QR-Code, NFC-Bump usw.) oder bitten Sie die Nutzer, das Token manuell einzugeben. Auf dem Gerät wird die in Schritt 1 angegebene Anmelde-URL geöffnet.
   2. Private Geräte: Bitten Sie die Nutzer, über die Einstellungen ein Arbeitsprofil hinzuzufügen. Wenn der Nutzer dazu aufgefordert wird, scannt er einen QR-Code mit dem signinEnrollmentToken oder gibt das Token manuell ein. Auf dem Gerät wird die in Schritt 1 angegebene Anmelde-URL geöffnet.
   3. Geräte im Privatbesitz: Stellen Sie Nutzern einen Registrierungstoken-Link zur Verfügung, wobei das Registrierungstoken signinEnrollmentToken ist. Auf dem Gerät wird die in Schritt 1 angegebene Anmelde-URL geöffnet.

3. Prüfe, ob Google den Nutzer bereits authentifiziert hat. Rufen Sie die Informationen zur Gerätebereitstellung (während der Geräteregistrierung) mit dem GET-Parameter provisioningInfo ab und prüfen Sie, ob das Feld authenticatedUserEmail einen Wert enthält. Wenn dieses Feld einen Wert enthält, wurde der Nutzer bereits erfolgreich von Google authentifiziert und Sie können diese Identität ohne weitere Authentifizierung verwenden.

4. Wenn Google den Nutzer noch nicht authentifiziert hat, sollte er über Ihre Anmelde-URL aufgefordert werden, seine Anmeldedaten einzugeben. Anhand der Identität können Sie die entsprechende Richtlinie ermitteln und die Informationen zur Gerätebereitstellung (während der Geräteregistrierung) mit dem GET-Parameter provisioningInfo abrufen.

5. Rufen Sie enrollmentTokens.create auf und geben Sie die entsprechende policyId basierend auf den Anmeldedaten des Nutzers an.

6. Geben Sie das in Schritt 5 generierte Registrierungstoken per URL-Weiterleitung im Format https://enterprise.google.com/android/enroll?et=<token> zurück.

Google-Authentifizierung mit Anmelde-URL-Ablauf erzwingen

Wenn Sie SigninDetail für die Anmeldung durch einen Drittanbieter (über „enterprises.create“ oder „enterprises.patch“) verwenden, können Sie googleAuthenticationOptions übergeben. Dadurch werden Regeln erzwungen, bevor der Nutzer zur Anmelde-URL des Drittanbieters weitergeleitet wird.

Wenn am Ende eines Ablaufs für die Anmeldung über eine URL ein EnrollmentToken erstellt wird, interagieren die Authentifizierungsanforderungen mit dem ursprünglichen SigninDetail:

• Wenn der Nutzer die Google-Anmeldung übersprungen hat, weil sie von SigninDetail nicht erforderlich war, aber die resultierende EnrollmentToken auf REQUIRED gesetzt ist, wird dem Nutzer ein Fehler angezeigt und er muss sich anmelden.
• Wenn requiredAccountEmail für das Token festgelegt ist und der Nutzer sich mit einer anderen Adresse des Unternehmens angemeldet hat, erhält er die Fehlermeldung „Falsches Konto“ und muss sich noch einmal mit der richtigen erforderlichen E-Mail-Adresse anmelden.

QR-Code-Methode

Android 7.0 oder höher

Wenn Sie ein unternehmenseigenes Gerät bereitstellen möchten, können Sie einen QR-Code generieren und in Ihrer EMM-Konsole anzeigen lassen:

1. Auf einem neuen oder auf die Werkseinstellungen zurückgesetzten Gerät tippt der Nutzer (in der Regel ein IT-Administrator) sechsmal auf dieselbe Stelle auf dem Display. Dadurch fordert das Gerät den Nutzer zum Scannen eines QR-Codes auf.
2. Der Nutzer scannt den QR-Code, den Sie in Ihrer Verwaltungskonsole (oder einer ähnlichen Anwendung) anzeigen, um das Gerät zu registrieren und bereitzustellen.

NFC-Methode

Android 6.0 oder höher

Für diese Methode müssen Sie eine NFC-Programmierer-App erstellen, die das Registrierungstoken, die anfänglichen Richtlinien und die WLAN-Konfiguration, die Einstellungen und alle anderen Bereitstellungsdetails enthält, die Ihr Kunde für die Bereitstellung eines vollständig verwalteten oder zweckbestimmten Geräts benötigt. Wenn Sie oder Ihr Kunde die NFC-Programmier-App auf einem Android-Gerät installieren, wird dieses Gerät zum Programmiergerät.

Eine detaillierte Anleitung zur Unterstützung der NFC-Methode finden Sie in der Entwicklerdokumentation zur Play EMM API. Die Website enthält auch Beispielcode der Standardparameter, die bei einer NFC-Transaktion an ein Gerät gesendet werden. Wenn Sie Android Device Policy installieren möchten, legen Sie den Downloadspeicherort des Geräteadministratorpakets auf Folgendes fest:

https://play.google.com/managed/downloadManagingApp?identifier=setup

DPC-ID-Methode

Wenn Android Device Policy nicht per QR-Code oder NFC hinzugefügt werden kann, kann ein Nutzer oder IT-Administrator ein unternehmenseigenes Gerät so bereitstellen:

1. Folgen Sie dem Einrichtungsassistenten auf einem neuen oder auf die Werkseinstellungen zurückgesetzten Gerät.
2. Geben Sie die WLAN-Anmeldedaten ein, um auf dem Gerät eine Internetverbindung herzustellen.
3. Wenn Sie zur Anmeldung aufgefordert werden, geben Sie afw#setup ein. Dadurch werden die Android-Geräterichtlinien heruntergeladen.
4. Scannen Sie einen QR-Code oder geben Sie ein Registrierungstoken manuell ein, um das Gerät bereitzustellen.

Zero-Touch-Registrierung

Android 8.0 oder höher (Pixel 7.1 oder höher)

Geräte, die bei einem autorisierten Zero-Touch-Reseller gekauft wurden, können für die Zero-Touch-Registrierung verwendet werden. Dies ist eine optimierte Methode zur Vorkonfiguration von Geräten, damit sie sich beim ersten Start automatisch bereitstellen.

Organisationen können Konfigurationen mit Bereitstellungsdetails für ihre Zero-Touch-Geräte erstellen, entweder über das Portal für die Zero-Touch-Registrierung oder über Ihre EMM-Konsole (siehe Zero-Touch Customer API). Beim ersten Startvorgang wird auf einem Zero-Touch-Gerät geprüft, ob ihm eine Konfiguration zugewiesen wurde. Wenn das der Fall ist, wird auf dem Gerät die Android Device Policy App heruntergeladen, durch die das Gerät dann mithilfe der in der zugewiesenen Konfiguration angegebenen Bereitstellungs-Extras fertig eingerichtet wird.

Wenn Ihre Kunden das Zero-Touch-Registrierungsportal verwenden, müssen sie für jede von ihnen erstellte Konfiguration Android Device Policy als EMM-DPC auswählen. Eine detaillierte Anleitung zur Verwendung des Portals, einschließlich des Erstellens und Zuweisens von Konfigurationen zu Geräten, finden Sie in der Android Enterprise-Hilfe.

Wenn Sie möchten, dass Ihre Kunden Konfigurationen direkt über Ihre EMM-Konsole festlegen und zuweisen, müssen Sie die Zero-Touch Customer API einbinden. Wenn Sie eine Konfiguration erstellen, geben Sie im Feld dpcExtras zusätzliche Bereitstellungsoptionen an. Das folgende JSON-Snippet zeigt ein einfaches Beispiel dafür, was in dpcExtras enthalten sein sollte, mit einem zusätzlichen Anmeldetoken.

{
   "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
   "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":"I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
   "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
      "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"{Sign In URL token}"
   }
}

App während der Einrichtung starten

In policies können Sie eine App angeben, die von Android Device Policy während der Einrichtung des Geräts oder des Arbeitsprofils gestartet werden soll. Sie können beispielsweise eine VPN-App starten, damit Nutzer im Rahmen der Einrichtung VPN-Einstellungen konfigurieren können. Die App muss RESULT_OK zurückgeben, um den Abschluss zu signalisieren und Android Device Policy die Bereitstellung des Geräts oder Arbeitsprofils zu ermöglichen. So startest du eine App während der Einrichtung:

Achten Sie darauf, dass die installType der App REQUIRED_FOR_SETUP ist. Wenn die App nicht auf dem Gerät installiert oder gestartet werden kann, schlägt die Bereitstellung fehl.

{
   "applications":[
      {
         "packageName":"com.my.vpnapp.",
         "installType":"REQUIRED_FOR_SETUP"
      }
   ]
}

Fügen Sie den Paketnamen der App zu setupActions hinzu. Mit title und description kannst du Anweisungen für Nutzer formulieren.

{
   "setupActions":[
      {
         "title":{
            "defaultMessage":"Configure VPN"
         },
         "description":{
            "defaultMessage":"Enable your VPN client to access corporate resources."
         },
         "launchApp":{
            "packageName":"com.my.vpnapp."
         }
      }
   ]
}

Damit du erkennen kannst, dass eine App über launchApp gestartet wird, enthält die Aktivität, die zuerst als Teil der App gestartet wird, das boolesche Intent-Extra com.google.android.apps.work.clouddpc.EXTRA_LAUNCHED_AS_SETUP_ACTION (auf true gesetzt). Mit diesem Extra kannst du deine App anpassen, je nachdem, ob sie über setupActions oder von einem Nutzer gestartet wird.

Nachdem die App RESULT_OK zurückgegeben hat, führt Android Device Policy alle verbleibenden Schritte aus, die für die Bereitstellung des Geräts oder Arbeitsprofils erforderlich sind.

Registrierung während der Einrichtung abbrechen

Die als SetupAction gestartete App kann die Registrierung abbrechen und RESULT_FIRST_USER zurückgeben.

Wenn Sie die Registrierung abbrechen, wird ein unternehmenseigenes Gerät zurückgesetzt oder das Arbeitsprofil auf einem privaten Gerät gelöscht.

Hinweis: Wenn Sie die Registrierung abbrechen, wird die Aktion ohne Bestätigungsdialogfeld für den Nutzer ausgelöst. Es liegt in der Verantwortung der App, dem Nutzer ein entsprechendes Fehlerdialogfeld anzuzeigen, bevor RESULT_FIRST_USER zurückgegeben wird.

Richtlinie auf neu registrierte Geräte anwenden

Welche Methode Sie verwenden, um Richtlinien auf neu registrierte Geräte anzuwenden, hängt von Ihren Anforderungen und denen Ihrer Kunden ab. Folgende Ansätze sind möglich:

• (Empfohlen) Beim Erstellen eines Registrierungstokens können Sie den Namen der Richtlinie (policyName) angeben, die anfänglich mit dem Gerät verknüpft wird. Wenn Sie ein Gerät mit dem Token registrieren, wird die Richtlinie automatisch auf das Gerät angewendet.

• Richtlinie als Standardrichtlinie für ein Unternehmen festlegen. Wenn im Registrierungstoken kein Richtlinienname angegeben ist und eine Richtlinie mit dem Namen enterprises/<enterprise_id>/policies/default vorhanden ist, wird jedes neue Gerät bei der Registrierung automatisch mit der Standardrichtlinie verknüpft.

• Abonnieren Sie ein Cloud Pub/Sub-Thema, um Benachrichtigungen zu neu registrierten Geräten zu erhalten. Rufen Sie als Antwort auf eine ENROLLMENT-Benachrichtigung enterprises.devices.patch auf, um das Gerät mit einer Richtlinie zu verknüpfen.

Gerät ohne Richtlinie registrieren

Wenn ein Gerät ohne gültige Richtlinie registriert wird, wird es in die Quarantäne verschoben. Geräte in Quarantäne sind für alle Gerätefunktionen gesperrt, bis das Gerät mit einer Richtlinie verknüpft ist.

Wenn ein Gerät nicht innerhalb von fünf Minuten mit einer Richtlinie verknüpft wird, schlägt die Geräteregistrierung fehl und das Gerät wird auf die Werkseinstellungen zurückgesetzt. Der Gerätestatus „In Quarantäne“ bietet Ihnen die Möglichkeit, im Rahmen Ihrer Lösung Lizenzprüfungen oder andere Prozesse zur Validierung der Registrierung zu implementieren.

Beispiel für einen Workflow zur Lizenzprüfung

1. Ein Gerät wird ohne Standardrichtlinie oder spezifische Richtlinie registriert.
2. Prüfen Sie, wie viele Lizenzen im Unternehmen noch verfügbar sind.
3. Wenn Lizenzen verfügbar sind, verwenden Sie devices.patch, um dem Gerät eine Richtlinie zuzuweisen, und verringern Sie dann die Anzahl der Lizenzen. Wenn keine Lizenzen verfügbar sind, verwenden Sie devices.patch, um das Gerät zu deaktivieren. Alternativ setzt die API jedes Gerät, das nicht innerhalb von fünf Minuten nach der Registrierung mit einer Richtlinie verknüpft ist, auf die Werkseinstellungen zurück.