Zarządzanie rolami aplikacji

Funkcja ról aplikacji umożliwia administratorowi IT przyznawanie specjalnych uprawnień zarządzanej aplikacji na urządzeniu z Androidem. Dzięki przypisaniu określonej roli aplikacja może być zwolniona z ograniczeń dotyczących zużycia energii i działania w tle, zawieszenia, hibernacji (na Androidzie 14 lub nowszym) oraz może mieć wyłączone elementy sterujące użytkownika (czyli działania użytkownika, takie jak wymuszenie zatrzymania i wyczyszczenie danych aplikacji) (na Androidzie 11 lub nowszym), co pozwala jej wykonywać krytyczne funkcje bez przerw. Ponadto aplikacja może otrzymywać powiadomienia o przypisanych rolach, co pozwala jej na samodzielne uruchamianie się bez interwencji użytkownika.

Listę dostępnych ról aplikacji i specjalnych uprawnień przyznanych każdej roli znajdziesz w artykule RoleType.

Wymagania wstępne

Urządzenie jest zarządzane przez usługę EMM opartą na AMAPI (usługi EMM korzystające z niestandardowego DPC nie są obsługiwane).

Przygotowanie aplikacji do korzystania z tej funkcji

Integracja z pakietem AMAPI SDK jest wymagana tylko wtedy, gdy aplikacja ma otrzymywać powiadomienia o przypisanych rolach, co pozwala jej na samodzielne uruchamianie się (czyli automatyczne uruchamianie bez interakcji z użytkownikiem).

Integracja z pakietem AMAPI SDK w aplikacji

Więcej informacji o pakiecie AMAPI SDK i sposobach dodawania go do aplikacji znajdziesz w przewodniku integracji z pakietem AMAPI SDK.

Dodawanie wymaganych metadanych do pliku manifestu aplikacji

Aplikacja Android Device Policy (ADP) musi znać ComponentName klasy, która implementuje NotificationReceiverService, aby powiadamiać aplikację o przypisanych rolach. Musisz odpowiednio otagować usługę w pliku AndroidManifest.xml, aby aplikacja ADP mogła ją automatycznie wykryć.

Aplikacja musi mieć dokładnie 1 usługę, która jest enabled i ma meta-data z android:name równym com.google.android.managementapi.notification.NotificationReceiverService.SERVICE_APP_ROLES
Ta usługa musi mieć ustawioną wartość android:exported na true.
Wartość android:value elementu meta-data musi być ustawiona na pusty ciąg znaków.

<service
 android:name=".MyNotificationReceiverService"
 android:exported="true">
    <meta-data android:name="com.google.android.managementapi.notification.NotificationReceiverService.SERVICE_APP_ROLES" android:value="" />
</service>

Jeśli testujesz rolę COMPANION_APP, musisz też dodać do usługi te meta-data, aby aplikacja Android Device Policy mogła wysyłać do Twojej aplikacji lokalne aktualizacje stanu poleceń:

<meta-data android:name="com.google.android.managementapi.notification.NotificationReceiverService.SERVICE_COMMAND_STATUS" android:value="" />

Tworzenie usługi rozszerzającej NotificationReceiverService (lub aktualizowanie istniejącej)

Utwórz lub zaktualizuj istniejącą NotificationReceiverService i zaimplementuj AppRolesListener, aby nasłuchiwać ról przypisanych do aplikacji. Do nasłuchiwania ról przypisanych do aplikacji wymagana jest tylko getAppRolesListener(). Jeśli do aplikacji przypisana jest rola COMPANION_APP, musisz też zaimplementować getCommandListener():

import android.util.Log
import com.google.android.managementapi.approles.AppRolesListener
import com.google.android.managementapi.approles.model.AppRolesSetRequest
import com.google.android.managementapi.approles.model.AppRolesSetResponse
import com.google.android.managementapi.commands.CommandListener
import com.google.android.managementapi.commands.model.Command
import com.google.android.managementapi.notification.NotificationReceiverService

class MyNotificationReceiverService : NotificationReceiverService() {

  // If your app wants to listen for roles assigned
  override fun getAppRolesListener(): AppRolesListener =
    object : AppRolesListener {
      override fun onAppRolesSet(request: AppRolesSetRequest): AppRolesSetResponse {
        val roleTypes = request.roles.map { role -> role.roleType }
        Log.i(TAG, "onAppRolesSet: $roleTypes")

        return AppRolesSetResponse.getDefaultInstance()
      }
    }

 // If your app wants to listen for local command status updates
 // Only relevant for COMPANION_APP role
 override fun getCommandListener(): CommandListener {
    return object : CommandListener {
      override fun onCommandStatusChanged(command: Command) {
         Log.i(TAG, "onCommandStatusChanged")
      }
    }
  }

  private companion object {
    const val TAG = "MyNotificationReceiverService"
  }
}

Jeśli role aplikacji zmienią się kilka razy, aplikacja może otrzymać kilka powiadomień. Jeśli wszystkie role zostaną usunięte, aplikacja nadal będzie powiadamiana o pustej liście ról. To powiadomienie spowoduje, że aplikacja wyjdzie ze stanu zatrzymania, a dzięki zwolnieniom przyznanym aplikacji będzie mogła się ona uruchomić bez interakcji z użytkownikiem. Dzięki powiadomieniom i zwolnieniom dotyczącym ról aplikacji aplikacja może nasłuchiwać transmisji ACTION_BOOT_COMPLETED. Jeśli aplikacja zależy od konfiguracji zarządzanych, aby się uruchomić, przeczytaj artykuł Konfigurowanie konfiguracji zarządzanych, aby dowiedzieć się, jak odczytywać zmiany i nasłuchiwać ich.

Konfigurowanie urządzenia za pomocą zasad dotyczących ról aplikacji

Deweloperzy aplikacji mogą testować przypisywanie ról aplikacji do swoich aplikacji za pomocą usługi EMM lub korzystając z przewodnika Szybki start dotyczącego Android Management API. Notatnik Colab AMAPI umożliwia zarejestrowanie firmy, utworzenie zasady i skonfigurowanie urządzenia.

Ustawianie zasady dla aplikacji z rolami aplikacji

Skonfiguruj policy z rolami aplikacji, które ma mieć aplikacja, za pomocą ApplicationPolicy.roles.

W tym przykładzie pokazujemy, jak skonfigurować rolę dla aplikacji MTD:

{
  "applications": [

    {
      "packageName": "com.example.mtd",
      "installType": "FORCE_INSTALLED",
      "roles": [
        { "roleType": "MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE" }
      ]
    }
  ]
}

Przed przypisaniem ról określonych w zasadach system sprawdzi, czy odcisk cyfrowy certyfikatu klucza podpisywania aplikacji na urządzeniu jest zgodny z odciskiem w Sklepie Play. Jeśli odcisk cyfrowy jest inny, role nie zostaną przypisane do aplikacji, a NonComplianceReason.APP_SIGNING_CERT_MISMATCH usługa EMM otrzyma raport o niezgodności.

{
  "applications": [

    {
      "packageName": "com.example.mtd",
      "installType": "FORCE_INSTALLED",
      "signingKeyCerts": [
         { "signingKeyCertFingerprintSha256": "base64-encoded-sha256" }
       ],
      "roles": [
        { "roleType": "MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE" }
      ]
    }
  ]
}

Jeśli aplikacja ma konfigurację zarządzaną, administrator IT może skonfigurować początkową konfigurację odpowiednich restriction w zasadach aplikacji:

{
  "applications": [

    {
      "packageName": "com.example.mtd",
      "installType": "FORCE_INSTALLED",
      "roles": [
        { "roleType": "MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE" }
      ],
      "managedConfiguration": {
        "<key>": "<value>"
      }
    }
  ]
}

Sprawdzanie stanu zwolnienia z ograniczeń dotyczących baterii

Aplikacje z rolą Mobile Threat Defense (MTD) są automatycznie zwolnione ze standardowych ograniczeń dotyczących zużycia energii w tle. To zwolnienie jest jednak implementowane przez zasobnik Czuwania aplikacji, a nie przez listę dozwolonych aplikacji systemowych.

Aby sprawdzić, czy zwolnienie aplikacji jest aktywne:

import android.app.usage.UsageStatsManager
import android.content.Context

// UsageStatsManager.STANDBY_BUCKET_EXEMPTED is annotated as a @SystemApi. We can redefine it for clarity.
// Define this at the top level of your file, or inside a companion object
private const val STANDBY_BUCKET_EXEMPTED = 5

private fun isAppExemptedFromAppStandbyBucket(): Boolean =
    (getSystemService(Context.USAGE_STATS_SERVICE) as? UsageStatsManager)
        ?.appStandbyBucket == STANDBY_BUCKET_EXEMPTED