Konfiguracje zarządzane w systemie Android: Konfigurowanie aplikacji dla pracowników, zanim je otworzą

Typowe zgłoszenie do wsparcia pierwszego dnia wygląda tak. Pracownik otwiera firmową aplikację, aplikacja pyta o adres serwera, a nikt na hali go nie zna. Ktoś z IT wpisuje wtedy ten sam adres URL, tę samą nazwę konta lub to samo ustawienie na każdym urządzeniu i prędzej czy później na którymś pojawia się literówka.

Android Enterprise oferuje standardowy sposób na uniknięcie tego problemu, zwany konfiguracjami zarządzanymi (managed configurations). Wartości aplikacji ustawia się raz w zasadach MDM. Trafiają one na każde urządzenie objęte tymi zasadami, a aplikacja odczytuje je podczas uruchamiania. Kiedy pracownik otwiera Chrome, klienta poczty, aplikację do skanowania lub własną aplikację biznesową, wie ona już, gdzie się połączyć i na co zezwalają uprawnienia.

Ten poradnik obejmuje obie strony konfiguracji. Dowiesz się, jak znaleźć i zastosować konfiguracje zarządzane dla popularnych aplikacji w edytorze zasad Twojego systemu MDM. Dowiesz się również, o co poprosić wewnętrznych programistów, aby Twoje własne pliki APK obsługiwały ten sam mechanizm.

Czym jest konfiguracja zarządzana i kto definiuje pola

Konfiguracja zarządzana to zestaw ustawień w postaci klucz-wartość, które organizacja przesyła do aplikacji na zarządzanym urządzeniu z systemem Android. Dokumentacja Android Enterprise firmy Google opisuje ten łańcuch w następujący sposób:

1. Programista aplikacji definiuje schemat. W pliku res/xml/app_restrictions.xml aplikacji programista deklaruje każde ustawienie akceptowane przez aplikację: jego klucz, typ (ciąg znaków, wartość logiczna, liczba całkowita, wybór, wielokrotny wybór, pakiet itp.), tytuł i wartość domyślną.
2. Google Play publikuje schemat. Po przesłaniu aplikacji do Google Play usługa Play odczytuje ten plik. Zarządzany sklep Google Play może następnie wyświetlać te pola w konsolach EMM w formie formularza.
3. Twój system MDM wysyła wartości. Za pośrednictwem interfejsu Android Management API wpis aplikacji w zasadach urządzenia przekazuje wybrane wartości.
4. Aplikacja je odczytuje. Na urządzeniu aplikacja wywołuje metodę RestrictionsManager.getApplicationRestrictions() i stosuje znalezione ustawienia.

Zatem to programista aplikacji decyduje, jakie pola istnieją, a nie Twój system MDM. Jeśli programista nie opublikował klucza „server URL”, żadna konsola nie może wstępnie skonfigurować adresu URL serwera. Konsola może wypełnić tylko te pola, które udostępnił programista.

Uwaga: Konfiguracje zarządzane różnią się od zasad urządzenia. Zasady urządzenia kontrolują sam system Android, na przykład aparat, port USB lub Wi-Fi. Konfiguracja zarządzana kontroluje ustawienia wewnątrz jednej konkretnej aplikacji. Zwykle potrzebujesz obu tych elementów.

Zanim zaczniesz

• Urządzenia są zarejestrowane w Twoim systemie MDM za pomocą Android Enterprise (jako w pełni zarządzane lub z profilem służbowym).
• Aplikacje, które chcesz skonfigurować, są zatwierdzone w zarządzanym sklepie Google Play lub są aplikacjami prywatnymi opublikowanymi tam przez Twoich programistów.
• Masz urządzenie testowe zarejestrowane w ramach zasad testowych, a nie produkcyjnych.
• Znasz wartości, które chcesz przesłać, takie jak nazwy hostów serwerów, dozwolone adresy URL i formaty kont.

Krok 1: Sprawdź, czy aplikacja obsługuje konfigurację zarządzaną

Zanim cokolwiek zaplanujesz, upewnij się, że aplikacja publikuje schemat. Możesz to sprawdzić w trzech miejscach:

1. W edytorze zasad Twojego systemu MDM. Dodaj aplikację do zasad testowych i sprawdź, czy pojawi się formularz konfiguracji. Jeśli tak, programista opublikował schemat.
2. W dokumentacji dla przedsiębiorstw dostawcy oprogramowania. Wielu dostawców publikuje swoje klucze. Na przykład Google wymienia zasady Chrome dla przedsiębiorstw wraz z obsługą platform pod adresem chromeenterprise.google/policies.
3. U zespołu pomocy technicznej dostawcy. Zapytaj: „Czy Wasza aplikacja na Androida obsługuje konfiguracje zarządzane Android Enterprise i jakie klucze udostępnia?”.

Zapisz każdy potrzebny klucz i jego typ. Typy schematu to m.in. string, bool, integer, choice, multi-select, hidden, bundle i bundle_array. Pole bool oczekuje wartości true lub false, a nie tekstu "true", a pole multi-select oczekuje wartości ze stałej listy.

Oczekiwany rezultat: Dla każdej aplikacji wiesz, czy obsługuje ona konfigurację zarządzaną i jakie pola będziesz ustawiać.

Ostrzeżenie: Jeśli aplikacja nie posiada schematu, w ramach systemu konfiguracji zarządzanych nie ma żadnego obejścia. Pozostaje poprosić dostawcę o jego dodanie, zmienić aplikację na inną lub zachować udokumentowany proces ręcznej konfiguracji dla tej aplikacji.

Krok 2: Dodaj aplikację do zasad i otwórz jej konfigurację

1. Otwórz zasady obejmujące urządzenia docelowe. Najpierw użyj zasad testowych.
2. Dodaj aplikację z zarządzanego sklepu Google Play, jeśli nie ma jej jeszcze w zasadach.
3. Otwórz formularz konfiguracji aplikacji.

W Nomid MDM karta aplikacji w edytorze zasad otwiera jej konfigurację zarządzaną. To zestaw ustawień, które deweloper publikuje przez Google Play, pokazany jako pola do wypełnienia. Własne aplikacje Nomid na Androida odczytują swoje ustawienia w ten sam sposób.

Oczekiwany rezultat: Zobaczysz formularz, którego pola odpowiadają kluczom wymienionym w Kroku 1.

Uwaga: Google Play odczytuje schemat z przesłanej aplikacji, więc formularz pojawia się dla aplikacji dystrybuowanych przez zarządzany Google Play, publicznych i prywatnych. W Nomid prywatne aplikacje hostowane w Nomid Store również pokazują formularz konfiguracji, jeśli przesłana aplikacja deklaruje schemat. W przypadku każdej innej drogi dystrybucji sprawdź, jak działa konfiguracja, zanim zaczniesz na niej polegać.

Krok 3: Wypełnij konfigurację dla popularnych aplikacji

Zanim wpiszesz wartości, przeczytaj kroki 4 i 5. Zdecyduj, które wartości są takie same dla wszystkich urządzeń objętych zasadami, a które różnią się w zależności od lokalizacji lub urządzenia, aby nie przebudowywać formularzy później.

Poniżej przedstawiono trzy schematy, których potrzebuje większość flot urządzeń. Nazwy pól różnią się w zależności od dostawców, dlatego potraktuj te klucze jako przykłady i sprawdź je we właściwym formularzu danej aplikacji.

3a. Przeglądarka: strona startowa i listy adresów URL (Chrome)

Chrome na Androida akceptuje wiele tych samych zasad dla przedsiębiorstw, co wersja komputerowa Chrome, dostarczanych jako konfiguracja zarządzana. Zasady często używane na urządzeniach pracowników obejmują:

Zanim oprzesz konfigurację na danej zasadzie, sprawdź listę zasad Chrome Enterprise, aby upewnić się, że jest ona obsługiwana w systemie Android. Niektóre zasady dla wersji stacjonarnej, zwłaszcza dotyczące uruchamiania i strony głównej, działają inaczej lub nie są dostępne na Androidzie. Jeśli potrzebujesz stałego ekranu startowego, zarządzane zakładki lub łącze internetowe w launcherze trybu kiosku są często bardziej przewidywalnymi rozwiązaniami. Jeśli blokujesz wszystko za pomocą URLBlocklist ["*"], dodaj do URLAllowlist również strony logowania dostawcy tożsamości, inaczej strony służbowe wymagające logowania się nie załadują.

3b. Klient poczty: serwer i konto

Aplikacje pocztowe dla przedsiębiorstw często udostępniają pola takie jak:

• Adres e-mail lub nazwa użytkownika
• Nazwa hosta serwera (na przykład host Exchange ActiveSync)
• Wymóg SSL/TLS
• Możliwość dodawania kont prywatnych

Wartości specyficzne dla użytkownika, takie jak adres e-mail, omówiono w Kroku 5. Na razie wypełnij pola, które są jednakowe dla wszystkich, takie jak host serwera i opcje zabezpieczeń.

3c. Skanery i aplikacje biznesowe: adres URL serwera i zachowanie

Narzędzia dla urządzeń wzmocnionych (rugged), aplikacje do skanowania i aplikacje biznesowe zazwyczaj udostępniają:

• Podstawowy adres URL backendu lub interfejsu API, na przykład https://wms.example.com/api
• Kod podmiotu (tenant), lokalizacji lub magazynu
• Przełączniki funkcji, takie jak tryb offline, skanowanie aparatem zamiast skanera sprzętowego lub wyłączenie rejestrowania debugowania

Zapisz zasady. Następnie upewnij się, że urządzenie testowe jest do nich przypisane. Oczekiwany rezultat: Formularz każdej aplikacji zawiera wspólne wartości tych zasad, zasady są zapisane, a urządzenie testowe z nich korzysta.

Ostrzeżenie: Unikaj umieszczania haseł lub długoterminowych poświadczeń w konfiguracji zarządzanej. Wartości te są przechowywane na urządzeniu i czytelne dla aplikacji. Lepiej stosować procesy, w których konfiguracja kieruje aplikację do właściwego serwera, a pracownik lub aplikacja dokonuje następnie uwierzytelnienia.

Krok 4: Ustaw raz na poziomie zasad

Konfiguracja zarządzana należy do zasad, a nie do pojedynczego urządzenia. Każde urządzenie objęte danymi zasadami otrzymuje te same wartości. Wykorzystaj to na swoją korzyść:

1. Grupuj urządzenia według różnic. Jeśli sklep A i sklep B korzystają z różnych adresów URL backendu, wymagają innej konfiguracji. Zorganizuj swoje zasady lub grupy zasad wokół tych różnic.
2. Wykorzystaj sprawdzoną konfigurację bazową. Zbuduj jedne w pełni skonfigurowane zasady i użyj ich jako punktu wyjścia dla nowych lokalizacji, aby nie tworzyć konfiguracji od nowa ręcznie. W Nomid do tego celu służą szablony zasad i grupy zasad.
3. Zmień raz, wdróż wszędzie. Kiedy adres URL serwera ulegnie zmianie, zmodyfikuj go w zasadach. Urządzenia pobiorą nową wartość podczas kolejnej synchronizacji zasad.

Oczekiwany rezultat: Każdy odrębny zestaw wartości odpowiada dokładnie jednym zasadom lub grupie zasad i nic nie jest konfigurowane ręcznie na poszczególnych urządzeniach.

Krok 5: Obsługa wartości specyficznych dla urządzenia

Niektóre wartości są inne na każdym urządzeniu: adres e-mail użytkownika, nazwa urządzenia, numer inwentarzowy (asset tag) lub numer seryjny potrzebny aplikacji do licencjonowania. Od wersji Android 10 zwykłe aplikacje nie mogą samodzielnie odczytać sprzętowego numeru seryjnego, dlatego przekazywanie go za pomocą konfiguracji zarządzanej jest powszechnym rozwiązaniem.

Istnieją dwa ogólne podejścia:

• Zmienne. Interfejs Android Management API pozwala konsoli dołączać zmienne konfiguracyjne do szablonu konfiguracji zarządzanej. Jeden szablon może następnie przyjmować różne wartości na poszczególnych urządzeniach. To, w jaki sposób konsola udostępnia tę funkcję i jakie zmienne oferuje, zależy od produktu. Zanim zaprojektujesz rozwiązanie, potwierdź u swojego dostawcy, jakie atrybuty urządzeń lub użytkowników można wstawiać.
• Mniejsze zakresy zasad. Jeśli wartość specyficzna dla urządzenia faktycznie odpowiada lokalizacji lub zespołowi, przypisz tej grupie własne zasady. Dla kilku urządzeń jest to proste. Dla setek przestaje być skalowalne – to znak, że potrzebujesz zmiennych lub zmian w aplikacji.

Trzecia opcja leży po stronie aplikacji. Aplikacja może pobrać wspólną wartość, taką jak identyfikator organizacji (tenant ID), z konfiguracji, a następnie po zalogowaniu pobrać ustawienia specyficzne dla danego urządzenia z własnego backendu. Rozwiązanie to sprawdza się często lepiej niż przesyłanie każdego szczegółu dotyczącego urządzenia przez system MDM.

Oczekiwany rezultat: Dla każdego pola ustalono, czy wartość jest wspólna (na poziomie zasad), zmienna (ustalana dla każdego urządzenia), czy też pobierana przez aplikację po zalogowaniu.

Krok 6: Sprawdź, czy aplikacja przyjęła zmiany

1. Potwierdź, że urządzenie otrzymało zasady. Sprawdź status ostatniej aktywności lub synchronizacji w konsoli. W Nomid lista zasobów pokazuje czas ostatniej aktywności i status kontaktu.
2. Sprawdź, czy aplikacja jest zainstalowana. Konfiguracja wysłana przed zakończeniem instalacji zostanie zastosowana, gdy aplikacja się pojawi, ale musi ona rzeczywiście zostać zainstalowana. Sprawdź listę aplikacji urządzenia w konsoli lub na samym urządzeniu.
3. Wymuś zatrzymanie aplikacji i otwórz ją ponownie. Wiele aplikacji odczytuje konfigurację tylko przy uruchomieniu. Wymuś zatrzymanie na stronie aplikacji w Ustawieniach. Jeśli zasady blokują Ustawienia, jak w kiosku, uruchom urządzenie ponownie, co można zrobić zdalnie.
4. Sprawdź działanie wewnątrz aplikacji. Pole serwera powinno być wstępnie wypełnione i zablokowane do edycji, zablokowana witryna powinna być niedostępna itd. Zdalny zrzut ekranu pozwala to sprawdzić bez konieczności fizycznego dostępu do urządzenia.

Oczekiwany rezultat: Na urządzeniu testowym każda skonfigurowana aplikacja pokazuje przesłane wartości bez ręcznego wpisywania. Następnie wdrażaj etapami: zapisz obecne wartości, aby móc je przywrócić, przenieś przetestowane wartości do zasad produkcyjnych, zastosuj je najpierw w małej grupie pilotażowej i rozszerz wdrożenie, gdy urządzenia pilotażowe pokażą prawidłowe wartości.

Uwaga: Jeśli po wymuszeniu zatrzymania aplikacja nadal wyświetla stare wartości, zapoznaj się z sekcją rozwiązywania problemów (FAQ) poniżej. Przyczyną jest zazwyczaj sposób, w jaki aplikacja obsługuje konfigurację, a nie samo jej dostarczenie.

Dla aplikacji wewnętrznych: poproś programistów o opublikowanie schematu

Jeśli Twoja własna aplikacja nadal wymaga od pracowników wpisywania adresu URL serwera, rozwiązanie znajduje się w kodzie aplikacji. Możesz przesłać swojemu zespołowi programistów poniższe wytyczne.

1. Zadeklaruj schemat

Utwórz plik res/xml/app_restrictions.xml:

<?xml version="1.0" encoding="utf-8"?>
<restrictions xmlns:android="http://schemas.android.com/apk/res/android">
    <restriction
        android:key="server_url"
        android:title="@string/cfg_server_url_title"
        android:description="@string/cfg_server_url_desc"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="site_code"
        android:title="@string/cfg_site_code_title"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="allow_offline"
        android:title="@string/cfg_offline_title"
        android:restrictionType="bool"
        android:defaultValue="false" />
</restrictions>

2. Dodaj odwołanie w manifeście

<application ...>
    <meta-data
        android:name="android.content.APP_RESTRICTIONS"
        android:resource="@xml/app_restrictions" />
</application>

3. Odczytaj wartości i reaguj na zmiany

class MainActivity : AppCompatActivity() {
    private val configReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context, intent: Intent) = applyConfig()
    }

    override fun onResume() {
        super.onResume()
        applyConfig() // picks up changes made while the app was in the background
        registerReceiver(
            configReceiver,
            IntentFilter(Intent.ACTION_APPLICATION_RESTRICTIONS_CHANGED)
        )
    }

    override fun onPause() {
        unregisterReceiver(configReceiver)
        super.onPause()
    }

    private fun applyConfig() {
        val rm = getSystemService(Context.RESTRICTIONS_SERVICE) as RestrictionsManager
        val config = rm.applicationRestrictions
        val serverUrl = config.getString("server_url", "")
        val allowOffline = config.getBoolean("allow_offline", false)
        // Apply serverUrl and allowOffline to the app's settings here
    }
}

Komunikat broadcastowy ACTION_APPLICATION_RESTRICTIONS_CHANGED jest dostarczany wyłącznie do odbiorców zarejestrowanych w trakcie działania programu (runtime). Aplikacja powinna również ponownie odczytywać konfigurację w metodzie onResume(), aby zastosować zmiany wprowadzone, gdy działała w tle.

4. Opublikuj w zarządzanym sklepie Google Play

Prześlij aplikację do Google Play — jako aplikację prywatną dla Twojej organizacji, jeśli nie jest publiczna — aby usługa Play mogła odczytać schemat i wyświetlić formularz w Twoim systemie MDM. Każde nowe wydanie, które dodaje lub zmienia nazwę klucza, wymaga przesłania nowej wersji.

Lista kontrolna dla programistów

• Zachowaj niezmienność kluczy. Zmiana nazwy server_url unieważnia wszystkie zasady, które go ustawiają.
• Ukryj pole w interfejsie użytkownika, gdy jest ustawione przez konfigurację, aby pracownicy nie mogli go nadpisać.
• Zapewnij bezpieczną obsługę wartości domyślnych, gdy klucz jest pusty, na przykład wyświetlając czytelny komunikat „skontaktuj się z działem IT”.
• Nigdy nie wymagaj haseł ani tokenów w konfiguracji. Użyj jej do wskazania serwera, a następnie przeprowadź właściwe uwierzytelnienie.
• Testuj za pomocą aplikacji TestDPC od Google na urządzeniu, które nie jest zarejestrowane w Twoim MDM. TestDPC musi być aplikacją zarządzającą urządzeniem, więc nie zadziała na urządzeniu, którym już zarządza Twój MDM.

Często zadawane pytania dotyczące rozwiązywania problemów

Aplikacja nie ma formularza konfiguracji w edytorze zasad.

Programista nie opublikował schematu w Google Play lub wersja w Play jest starsza niż wdrożony schemat. Sprawdź dokumentację dostawcy lub zapytaj go bezpośrednio. W przypadku aplikacji wewnętrznych upewnij się, że wpis meta-data istnieje w manifeście oraz że wersja ze schematem została przesłana. Klucz dodany w nowej wersji pojawia się w formularzu dopiero po przesłaniu tej wersji do Google Play i jej przetworzeniu.

Wartość została zmieniona, ale aplikacja nadal wyświetla starą.

Sprawdź kolejno następujące kwestie:

1. Czy urządzenie zsynchronizowało zaktualizowane zasady? Sprawdź czas ostatniej aktywności.
2. Wymuś zatrzymanie i otwórz aplikację ponownie. Jeśli nowa wartość się pojawi, oznacza to, że aplikacja odczytuje konfigurację tylko przy uruchomieniu i nie nasłuchuje komunikatów o zmianach.
3. Jeśli nadal się nie pojawia, aplikacja mogła zapisać starą wartość we własnej pamięci. Wyczyszczenie danych aplikacji to naprawia, ale usuwa wszystko, co jest zapisane tylko na urządzeniu, np. niezsynchronizowane skany offline, więc najpierw wykonaj synchronizację. W przeciwnym razie deweloper musi poprawić aplikację.

Wartość dociera, ale aplikacja ją ignoruje.

Upewnij się, że nazwa klucza i typ dokładnie odpowiadają schematowi. W kluczach rozróżniana jest wielkość liter, a wartość logiczna przesłana jako ciąg znaków nie zostanie odczytana jako boolean. Sprawdź także, czy wersja aplikacji na urządzeniu nie jest starsza niż ta, która wprowadziła dany klucz. Na urządzeniu z profilem służbowym sprawdź, czy pracownik otworzył służbową kopię aplikacji, oznaczoną ikoną teczki. Kopia prywatna nigdy nie otrzymuje konfiguracji.

Niektóre zasady Chrome działają, a inne nie.

Nie każda zasada Chrome Enterprise jest obsługiwana w systemie Android. Sprawdź obsługę platform dla każdej z nich na liście zasad Chrome Enterprise i sprawdź wersję Chrome na urządzeniu.

Czy mogę przesłać inną wartość na każde urządzenie?

Tak, ale nie jest to domyślne zachowanie. Użyj zmiennych konfiguracyjnych, jeśli Twoja konsola je obsługuje dla wymaganego atrybutu, podziel urządzenia na mniejsze zasady lub skonfiguruj aplikację tak, aby pobierała ustawienia urządzenia z własnego backendu. Zobacz Krok 5.

Konfiguracja została zastosowana, ale pracownik nadal może edytować pole.

Blokowanie pola to zadanie aplikacji, a nie systemu Android. Poproś programistę o wyłączenie lub ukrycie ustawień pochodzących z konfiguracji zarządzanej.

Jak testować bez wpływu na środowisko produkcyjne?

Użyj dedykowanych zasad testowych i jednego zarejestrowanego urządzenia. W przypadku aplikacji wewnętrznych programiści mogą użyć aplikacji TestDPC, zanim aplikacja w ogóle trafi do Twojego systemu MDM.

Następne kroki

Główne wnioski:

• Programista aplikacji definiuje, co można skonfigurować. Twój system MDM wypełnia te pola i nic więcej.
• Najpierw potwierdź obsługę, zanotuj klucze i typy oraz przetestuj na jednym urządzeniu przed wdrożeniem na szerszą skalę.
• Wspólne wartości należą do zasad. Wartości specyficzne dla urządzenia wymagają zmiennych, mniejszych zakresów lub pobierania po stronie aplikacji.
• W przypadku aplikacji wewnętrznych dodanie schematu wymaga niewielkiej, dobrze udokumentowanej zmiany i eliminuje konieczność ręcznej konfiguracji przez pracowników.

Zacznij w tym tygodniu od aplikacji, która generuje najwięcej zgłoszeń związanych z konfiguracją. Wypisz jej klucze, stwórz zasady testowe i zweryfikuj je na jednym urządzeniu. Następnie wyślij powyższą listę kontrolną zespołowi odpowiedzialnemu za Twoją aplikację wewnętrzną.

Jeśli chcesz wypróbować ten proces z Nomid MDM, karta aplikacji w edytorze zasad otwiera konfigurację zarządzaną każdej aplikacji, a bezpłatny plan obejmuje do 10 urządzeń bez ograniczeń czasowych. To wystarcza na zasady testowe i grupę pilotażową. Zdalny dostęp i interfejs API nie są zawarte w bezpłatnym planie.

FAQ

Czym jest konfiguracja zarządzana w systemie Android?

Jest to zestaw ustawień w formacie klucz-wartość przesyłanych przez organizację do aplikacji na zarządzanym urządzeniu z systemem Android. Przykłady obejmują adres URL serwera, dozwolone witryny internetowe lub przełączniki funkcji. Programista aplikacji definiuje dostępne pola w schemacie opublikowanym w Google Play, a system MDM przesyła wartości za pośrednictwem zasad urządzenia.

Skąd mam wiedzieć, czy aplikacja obsługuje konfigurację aplikacji w Android Enterprise?

Dodaj aplikację do zasad testowych w swoim systemie MDM i sprawdź, czy pojawi się formularz konfiguracji. Możesz także sprawdzić dokumentację enterprise dostawcy lub zapytać jego zespół pomocy technicznej, jakie klucze konfiguracji zarządzanej udostępnia aplikacja.

Czym jest app_restrictions.xml?

Jest to plik XML w zasobach aplikacji na Androida, w którym programista deklaruje schemat konfiguracji zarządzanej: klucz każdego ustawienia, typ, tytuł i wartość domyślną. Odwołanie do pliku znajduje się w manifeście aplikacji, a usługa Google Play odczytuje go po przesłaniu aplikacji.

Czy zmiana konfiguracji zarządzanej jest stosowana natychmiast?

Urządzenie otrzymuje ją podczas kolejnej synchronizacji zasad. To, czy aplikacja zastosuje ją od razu, zależy od samej aplikacji. Aplikacje nasłuchujące komunikatu o zmianie ograniczeń (restrictions-changed) aktualizują się podczas działania, podczas gdy inne odczytują konfigurację dopiero przy następnym uruchomieniu.