Intune App SDK för Android – MAM Integration Essentials

Med Microsoft Intune App SDK för Android kan du införliva Intune appskyddsprinciper (kallas även MAM-principer) i din interna Java/Kotlin Android-app. Ett Intune-hanterat program är ett program som är integrerat med Intune App SDK. Intune administratörer kan enkelt distribuera appskyddsprinciper till din Intune hanterade app när Intune aktivt hanterar appen.

Steg 4: MAM Integration Essentials

Etappmål

• Aktivera strikt MAM-läge.
• Registrera dig för kritiska meddelanden från SDK.
• Implementera och registrera en motringning för autentisering för att tillhandahålla Microsoft Entra token från MSAL till SDK.
• Registrera nya konton för MAM-hantering efter autentisering med MSAL.
• Avregistrera konton vid utloggning för att ta bort företagsdata.
• (Rekommenderas) Integrera MAM-loggning i din app.
• (Rekommenderas) Lär dig hur du använder dialogrutan SDK-diagnostik.

Bakgrund

Nu när du har laddat ned Intune App SDK, integrerat i din version och utfört klass- och metodbyten är det dags att göra viktiga kodändringar för att börja tillämpa principinställningar för appskydd för MAM-skyddade konton.

I det här steget instrueras du om hur du ansluter till SDK: s loggning, anropar en diagnostikdialogruta, aktiverar MAM strikt läge för att identifiera möjliga integrationsbuggar, registrerar för meddelanden från SDK och viktigast av allt, hur du registrerar ett konto för Intune MAM för att börja ta emot princip.

Strikt MAM-läge

MAM strikt läge kan identifiera potentiella buggar i programmets integrering av Intune App SDK. Dessa integreringsbuggar kan resultera i att appskyddsprincipen inte kan tillämpas korrekt och att företagsdata lämnas oskyddade. Därför måste MAM använda strikt läge.

Strikt MAM-läge letar efter avvikelser i programmets användning av MAM-API:er och MAM-begränsade plattforms-API:er. Löst mönstrat efter Androids StrictMode kör MAM Strict Mode en fördefinierad uppsättning kontroller som genererar körningsfel när de misslyckas. Strikt MAM-läge är inte avsett att vara aktiverat i produktionsversioner. Använd den i stället i appens interna utveckling, felsökning och/eller dogfood-versioner.

Om du vill aktivera strikt läge för MAM anropar du följande metod tidigt i programinitieringen (till exempel Application.onCreate):

MAMStrictMode.enable();

När en MAM-kontroll i strikt läge misslyckas kan du försöka avgöra om det är ett verkligt problem som kan åtgärdas i din app eller en falsk positiv. Om du tror att det är en falsk positiv eller om du är osäker kan du meddela Intune MAM-teamet. Det gör att vi kan bekräfta att vi håller med om den falska positiva identifieringen och försöka förbättra identifieringen för framtida versioner. Om du vill förhindra falska positiva identifieringar inaktiverar du den misslyckade kontrollen enligt anvisningarna nedan.

Hantera överträdelser

När en kontroll misslyckas kör den en MAMStrictViolationHandler. Standardhanteraren genererar ett Error, som förväntas krascha appen. Detta är för att göra felen så brus som möjligt och passar in i avsikten att strikt läge inte ska aktiveras i produktionsversioner.

Om din app vill hantera överträdelser på ett annat sätt kan den ange sin egen hanterare genom att anropa följande metod där handler implementerar MAMStrictViolationHandler:

MAMStrictMode.global().setHandler(handler);

Döljer kontroller

Om en kontroll misslyckas i en situation där din app inte gör något felaktigt rapporterar du det enligt ovan. Under tiden kan det vara nödvändigt att inaktivera kontrollen som påträffade en falsk positiv, åtminstone i väntan på en uppdaterad SDK. Kontrollen som misslyckades visas i felet som utlöses av standardhanteraren eller så skickas den till en anpassad hanterare, om den har angetts.

Även om undertryckningar kan göras globalt rekommenderar vi att du tillfälligt inaktiverar per tråd på den specifika anropsplatsen. Följande exempel visar olika sätt att inaktivera MAMStrictCheck.IDENTITY_NO_SUCH_FILE (höjs om ett försök görs att skydda en fil som inte finns).

Per-Thread Tillfällig undertryckning

Det här är den rekommenderade undertryckningsmekanismen.

try (StrictScopedDisable disable = MAMStrictMode.thread().disableScoped(MAMStrictCheck.IDENTITY_NO_SUCH_FILE)) {
    // Perform the operation which raised a violation here
}
// The check is no longer disabled once the block exits

Per-Thread Permanent undertryckning

MAMStrictMode.thread().disable(MAMStrictCheck.IDENTITY_NO_SUCH_FILE);

Globalt (processomfattande) undertryck

MAMStrictMode.global().disable(MAMStrictCheck.IDENTITY_NO_SUCH_FILE);

Registrera dig för meddelanden från SDK

Intune App SDK utfärdar många olika typer av meddelanden för att informera program om tidskänsliga hanteringsåtgärder. Ditt program kan registrera sig för och vidta åtgärder när du tar emot något av dessa meddelanden.

När en IT-administratör till exempel utfärdar ett selektivt rensningskommando för en enhet skickar Intune-tjänsten ned ett meddelande till SDK, som skickas vidare till ditt program somWIPE_USER_DATA. Ditt program kan lyssna efter det här meddelandet och kontrollera vilka data som rensas. eller så kan den förlita sig på SDK:s standardrensningsbeteende.

Många av meddelandena är valfria. Beroende på vilka SDK-funktioner programmet använder kan vissa meddelanden krävas. Se Registrera dig för meddelanden från SDK i steg 7: Funktioner för appdeltagande för mer information om hur du registrerar dig för meddelanden, vilka meddelanden SDK:et levererar och hur du hanterar specifika meddelandetyper.

Registrering för appskyddsprincip

När administratörer skapar appskyddsprinciper riktar de dessa principer mot specifika konton i organisationen. På klienten måste SDK:n veta vilket konto som använder programmet så att det kan hämta kontots princip och tillämpa inställningarna på rätt sätt. Din app ansvarar för att tillhandahålla SDK:n med den här kontoinformationen. Den här processen kallas registrering.

När appen lägger till ett nytt konto måste det registrera kontot med SDK:et, även om andra konton redan är registrerade. Din app kan registrera flera konton. För närvarande går det dock bara att registrera ett konto eller att en appskyddsprincip tillämpas. I Android är den här begränsningen för ett hanterat konto enhetsomfattande.

Registrering jämfört med registrering

Registrering är den process där din app informerar SDK om att ett nytt konto används. SDK innehåller funktioner som din app måste anropa för registrering och avregistrering av konton.

Registrering är den process där SDK registrerar det registrerade kontot med Intune-tjänsten så att det kan tillämpa kontots princip. Din app behöver inte anropa några funktioner för registrering. SDK:n hanterar registreringen fullständigt när ett konto har registrerats.

Om ett konto redan har registrerats för ditt program registreras inte det andra kontot och principen tillämpas inte när det registrerar ett annat konto, även om det kontot är mål för appskyddsprinciper.

Implementera registrering

Din app måste göra tre kodändringar för att kunna registrera ett konto:

1. Appen måste implementera och registrera en instans av gränssnittet MAMServiceAuthenticationCallback eller MAMServiceAuthenticationCallbackExtended . Återanropsinstansen onCreate() måste vara registrerad i metoden (eller onMAMCreate()) i underklassen Application.

2. När ett konto skapas och användaren loggar in med MSAL måste appen anropa registerAccountForMAM.

3. När ett konto tas bort ska appen anropa unregisterAccountForMAM för att ta bort kontot från Intune -hantering.

   Försiktighet

   Samtalet kan initiera en rensning för att helt ta bort företagsdata för kontot.

Alla nödvändiga API:er för autentisering och registrering finns i MAMEnrollmentManager-gränssnittet . En referens till kan MAMEnrollmentManager erhållas på följande sätt:

MAMEnrollmentManager mgr = MAMComponents.get(MAMEnrollmentManager.class);

// make use of mgr

Den returnerade instansen MAMEnrollmentManager är garanterat inte null. API-metoderna kan delas in i två kategorier: autentisering och kontoregistrering.

MAMEnrollmentManager och autentisering

SDK kommunicerar ofta med Intune -tjänsten: för registrering av registrerade konton, för att få uppdateringar av inställningar för appskyddsprinciper och för att få väntande administratörsåtgärder, till exempel selektivt rensa skyddade data i din app. För att kunna kommunicera med Intune -tjänsten kräver SDK nya åtkomsttoken från appar som har integrerat MSAL.

Om SDK inte kan hämta en ny token kan den inte kommunicera med Intune-tjänsten, vilket kan fördröja hämtning och tillämpning av nya principinställningar eller administratörsåtgärder. Det är viktigt att din app slutför de här stegen för att säkerställa sömlös tillämpning av principen.

I steg 2 integrerade du MSAL i ditt program för autentisering och förvärv av åtkomsttoken. Här implementerar du ett autentiseringsåteranrop så att SDK:n kan begära nödvändiga token.

MAMEnrollmentManager har följande autentiseringsmetoder:

interface MAMServiceAuthenticationCallback {
    String acquireToken(String upn, String aadId, String resourceId);
}
interface MAMServiceAuthenticationCallbackExtended extends MAMServiceAuthenticationCallback {
    String acquireToken(String upn, String aadId, String tenantId, String authority, String resourceId);
}
void registerAuthenticationCallback(MAMServiceAuthenticationCallback callback);
void updateToken(String upn, String aadId, String resourceId, String token);

1. Appen måste implementera MAMServiceAuthenticationCallback-gränssnittet eller MAMServiceAuthenticationCallbackExtended-gränssnittet så att SDK kan begära en Microsoft Entra token för det angivna kontot och resurs-ID. Motringningsinstansen måste anges till genom MAMEnrollmentManager att anropa dess registerAuthenticationCallback metod. En token kan behövas tidigt i appens livscykel för återförsök av registrering eller incheckningar för uppdatering av appskyddsprinciper, så motringningen måste registreras i onCreate() metoden (eller onMAMCreate()) för appens Application underklass.

2. Metoden acquireToken bör hämta åtkomsttoken för det begärda resurs-ID:t för det angivna kontot. Om den inte kan hämta den begärda token bör den returnera null.

   Tips

   Se till att din app använder parametrarna resourceIdaadId och skickas till acquireToken() så att rätt token hämtas. Parametern upn är endast avsedd för informationsanvändning. Den ska inte användas för att identifiera ett konto utan att även ta hänsyn till .aadId De resourceId ska användas för att generera rätt omfång och ska aadId användas för att skicka vidare rätt konto. Om token returneras för fel konto och/eller fel resurs kan de orsaka fördröjningar eller fel vid registrering av appen och hämtning av principer. Om din app behöver Microsoft Entra Authority för att hämta token korrekt implementerar du gränssnittetMAMServiceAuthenticationCallbackExtended.

   class MAMAuthCallback implements MAMServiceAuthenticationCallbackExtended {
       public String acquireToken(String upn, String aadId,
                   String tenantId, String authority, String resourceId) {
           final String[] scopes = {resourceId + "/.default"};
   
           final IAccount account = getAccount(aadId);
           if (account == null) {
               // Log error or warning here about: "no account found for " + aadId
               return null;
           }
   
           AcquireTokenSilentParameters params =
               new AcquireTokenSilentParameters.Builder()
                       .forAccount(account)
                       .fromAuthority(account.getAuthority())
                       .withScopes(Arrays.asList(scopes))
                       .withCallback(callback)
                       .build();
   
           return mMsalClientApplication.acquireTokenSilent(params);
       }
   
       private static IAccount getAccount(String aadId) throws InterruptedException, MsalException {
         IAccount account = null;
   
         if (mMsalClientApplication instanceof IMultipleAccountPublicClientApplication) {
             IMultipleAccountPublicClientApplication multiAccountPCA =
                     (IMultipleAccountPublicClientApplication) mMsalClientApplication;
   
             account = multiAccountPCA.getAccount(aadId);
         } else {
             ISingleAccountPublicClientApplication singleAccountPCA =
                     (ISingleAccountPublicClientApplication) mMsalClientApplication;
   
             ICurrentAccountResult accountResult = singleAccountPCA.getCurrentAccount();
             if (accountResult != null) {
                 account = accountResult.getCurrentAccount();
                 // make sure this is the correct user
                 if (account != null && !account.getId().equals(aadId))
                     account = null;
             }
         }
         return account;
     }
   }
   

3. Om appen inte kan tillhandahålla en token när SDK:n anropar acquireToken() , till exempel om tyst autentisering misslyckas och det är en olämplig tid att visa ett användargränssnitt, kan appen tillhandahålla en token vid ett senare tillfälle genom att anropa updateToken metoden . Samma UPN, Microsoft Entra ID och resurs-ID som begärdes av föregående anrop måste acquireToken() skickas till updateToken(), tillsammans med den token som slutligen förvärvades. Parametern upn är endast i informationssyfte och ignoreras vanligtvis av MAM SDK. Appen bör anropa den här metoden så snart som möjligt efter att ha returnerat null från det angivna återanropet.

   Varning

   Anropa updateToken() inte inifrån din implementering av acquireToken(). updateToken() bör användas i de fall där acquireToken() det inte går att hämta en token.

   Obs!

   SDK:n anropar acquireToken() regelbundet för att hämta token, så anrop updateToken() krävs inte strikt. Det rekommenderas dock starkt eftersom det kan hjälpa registreringar och incheckningar av programskyddsprinciper att slutföras i tid.

Implementeringsanteckningar för autentisering

• Appar uppmanas att hämta Microsoft Entra token innan de anroparregisterAccountForMAM. När du har registrerat ett konto får appar ett återanrop till den registrerade MAMServiceAuthenticationCallbackmetoden acquireToken() i en annan tråd. Genom att ange en giltig token i det motringningen kan registreringen fortsätta. Appen får registreringsresultatet via ett meddelande.

• Om appen inte returnerar en giltig Microsoft Entra-token blir AUTHORIZATION_NEEDEDslutresultatet från registreringsförsöket . Om appen tar emot det här resultatet via ett meddelande rekommenderar vi att du påskyndar registreringsprocessen genom att hämta token för kontot och resursen som tidigare begärts från acquireToken och anropa updateToken metoden för att initiera registreringsprocessen igen.

• Appens registrerade MAMServiceAuthenticationCallback anropas också för att hämta en token för regelbundna incheckningar av appskyddsprinciper. Om appen inte kan tillhandahålla en token på begäran får den inget meddelande, men den bör försöka hämta en token och ringa updateToken() vid nästa lämpliga tidpunkt för att påskynda incheckningsprocessen. Om en token inte anges kan motringningen fortfarande anropas vid nästa incheckningsförsök.

• Stöd för suveräna moln kräver att du tillhandahåller behörighet.

• Om MAMServiceAuthenticationCallbackExtended gränssnittet implementeras behöver den ärvda acquireToken() metoden från MAMServiceAuthenticationCallback inte implementeras, eftersom MAMServiceAuthenticationCallbackExtended gränssnittet tillhandahåller en standardimplementering.

MAMEnrollmentManager och registrering

När appen lägger till ett konto måste den registrera kontot med SDK:n. När appen tar bort ett konto bör den på samma sätt avregistrera det kontot för att ange att appen inte längre ska tillämpa policyn för det kontot. Om kontot har registrerats i MAM-tjänsten avregistreras kontot och appen rensas.

MAMEnrollmentManager har följande metoder för kontoregistrering:

void registerAccountForMAM(String upn, String aadId, String tenantId);
void registerAccountForMAM(String upn, String aadId, String tenantId, String authority);
void unregisterAccountForMAM(String upn, String aadId);
Result getRegisteredAccountStatus(String upn, String aadId);

1. För att registrera ett konto för hantering ska appen anropa registerAccountForMAM(). Ett konto identifieras med både dess UPN och dess användar-ID för Microsoft Entra. Klientorganisations-ID krävs också för att associera registreringsdata med kontots Microsoft Entra klientorganisation. Kontots behörighet kan också tillhandahållas för att tillåta registrering mot specifika suveräna moln. Mer information finns i Sovereign Cloud Registration. SDK:n kan försöka registrera appen för det angivna kontot i MAM-tjänsten. Om registreringen misslyckas försöker du regelbundet registrera igen tills registreringen lyckas eller kontot inte är registrerat. Återförsöksperioden är vanligtvis 12–24 timmar. SDK:n tillhandahåller status för registreringsförsök asynkront via meddelanden.

2. Den bästa tiden att ringa registerAccountForMAM är när användaren har loggat in på appen och har autentiserats med MSAL. Kontots användar-ID för Microsoft Entra, klientorganisations-ID och utfärdare returneras från MSAL-autentiseringsanropet som en del av IAccount relaterat till IAuthenticationResult.

   • Kontot kommer från IAuthenticationResult.getAccount() metoden och innehåller relevant kontoinformation.
   • AAD-ID (även kallat Microsoft Entra ID eller OID) kommer från IAccount.getId() metoden.
   • Klientorganisations-ID:t kommer från IAccount.getTenantId() metoden.
   • Auktoriteten IAccount.getAuthority() kommer från metoden.

3. Om du vill avregistrera ett konto från Intune -hantering ska appen anropa unregisterAccountForMAM(). Om kontot har registrerats och hanteras avregistrerar SDK:n kontot och rensar dess data. Regelbundna registreringsförsök för kontot stoppas. SDK:n tillhandahåller status för avregistreringsbegäranden asynkront via meddelande.

Implementeringsanteckningar för registrering

• Registreringsmetoderna är idempotenta. RegisterAccountForMAM registrerar till exempel bara ett konto och försöker registrera appen om kontot inte redan är registrerat, och unregisterAccountForMAM avregistrerar bara ett konto om det för närvarande är registrerat. Efterföljande anrop är no-ops, så det skadar inte att anropa dessa metoder mer än en gång.

• Det finns ingen garanti för att varje registrerat/avregistrerat anrop har ett motsvarande resultatmeddelande. Om registerAccountForMAM() du till exempel anropar ett konto som redan har registrerats kanske inte meddelandet skickas igen för den identiteten. Alternativt kan SDK skicka meddelanden även när din app inte anropade dessa metoder, eftersom SDK regelbundet kan försöka registrera i bakgrunden och avregistreringar kan utlösas av rensningsbegäranden som tas emot från Intune tjänsten.

• Registreringsmetoderna kan anropas för valfritt antal olika konton, men för närvarande kan endast ett konto registreras. Om flera konton som är licensierade för Intune och mål med appskyddsprincip registreras samtidigt eller nästan samtidigt finns det ingen garanti för vilket som vinner loppet.

• Du kan fråga MAMEnrollmentManager för att se om ett visst konto är registrerat och få dess aktuella status med hjälp av metoden getRegisteredAccountStatus . Om det angivna kontot inte är registrerat returnerar den här metoden null. Om kontot är registrerat returnerar den här metoden kontots status som en av medlemmarna i MAMEnrollmentManager.Result uppräkningen.

Sovereign Cloud Registration

Azure stöder flera fysiskt isolerade moln, som kallas nationella eller nationella moln. Om ditt program är molnmedvetet i en suverän statmåste det ange authority parametern till registerAccountForMAM().

MSAL-vägledning

För MSAL anges multiple_clouds_supported i trueMSAL-konfigurationsfilen.

{
  "multiple_clouds_supported": true,
}

Registreringsresultat och statuskoder

När ett konto först registreras börjar det i tillståndet PENDING , vilket indikerar att det första registreringsförsöket för MAM-tjänsten är ofullständigt. När registreringsförsöket är klart skickas ett meddelande med en av resultatkoderna i tabellen nedan. Dessutom returnerar metoden getRegisteredAccountStatus kontots status så att appen alltid kan avgöra om kontot har appskyddsprinciper tillämpade. Om registreringsförsöket misslyckas kan kontots status ändras med tiden när SDK:n försöker registrera igen i bakgrunden.

(Rekommenderas) Loggning

Loggningen bör initieras tidigt för att få ut mesta möjliga värde av loggade data. Application.onMAMCreate() är vanligtvis det bästa stället att initiera loggning.

Om du vill ta emot MAM-loggar i din app skapar du en Java-hanterare och lägger till den i MAMLogHandlerWrapper. Detta anropar publish() programhanteraren för varje loggmeddelande.

/**
 * Global log handler that enables fine grained PII filtering within MAM logs.
 * To start using this you should build your own log handler and add it via
 * MAMComponents.get(MAMLogHandlerWrapper.class).addHandler(myHandler, false);
 * You may also remove the handler entirely via
 * MAMComponents.get(MAMLogHandlerWrapper.class).removeHandler(myHandler);
 */
public interface MAMLogHandlerWrapper {
    /**
     * Add a handler, PII can be toggled.
     * @param handler handler to add.
     * @param wantsPII if PII is desired in the logs.
     */
    void addHandler(final Handler handler, final boolean wantsPII);

    /**
     * Remove a handler.
     * @param handler handler to remove.
     */
    void removeHandler(final Handler handler);
}

(Rekommenderas) Information om diagnostik

Appen Intune-företagsportal har flera alternativ för insamling av diagnostikinformation. Företagsportalen innehåller användargränssnitt som:

• Gör att användarna kan samla in företagsportals loggar.
• Visar enhets- och kontometadata.
• Innehåller information per app om aktuell MAM-policy.

Intune

En detaljerad förklaring av de data som ingår i företagsportalens loggar och i diagnostikgränssnittet finns i Förstå företagsportals loggar i bilagan.

Appar kan starta det här diagnostikgränssnittet genom att anropa MAMPolicyManager.showDiagnostics(context). Slutanvändarna kan också starta företagsportalens diagnostikkonsol via Microsoft Edge genom att ange about:intunehelp i adressfältet. Det här är en valfri funktion som kan hjälpa dig vid felsökning.

Den här diagnostikinformationen är bara tillgänglig när företagsportalen är installerad på enheten. En varningsdialogruta visas när showDiagnostics anropas utan att företagsportalen är installerad.

Villkor för att avsluta

Vid den här tidpunkten i integreringen kan din app nu ta emot och tillämpa appskyddsprincip. Utför följande tester för att verifiera integreringen.

Test för den första principtillämpningen

Kör följande test först för att bekanta dig med den fullständiga slutanvändarupplevelsen av principtillämpning i din app:

1. Skapa en Android-appskyddsprincip i Microsoft Intune administrationscenter (mer information finns i Skapa en testprincip för Android-appskydd i steg 1). För det här testet konfigurerar du principen:
   • Under Dataskydd ställer du in "Skärmdump och Google Assistant" på "Blockera".
   • Låt standardinställningarna vara kvar under Åtkomstkrav. Noterbart är att "PIN for Access" ska vara "Require".
2. Se till att appskyddsprincipen är riktad mot ditt program. Du måste förmodligen lägga till paketnamnet manuellt i guiden för att skapa principer.
3. Tilldela appskyddsprincipen till en användargrupp som innehåller testkontot.
4. Avinstallera andra SDK-integrerade appar, till exempel Outlook, Teams, OneDrive och Office på en Android-testenhet. Avinstallera även appen Intune-företagsportal och Microsoft Authenticator-appen.

   • Tips

     Om du avinstallerar andra SDK-integrerade appar kan du vara säker på att du uteslutande testar integreringen av din egen app.

5. Installera programmet.
6. Logga in på ditt program med ditt testkonto som är mål för appskyddsprincipen.
7. Bekräfta att du uppmanas att installera Intune-företagsportalen från Google Play.

   • Obs!

     Om testenheten inte har Google Play Store-appen bekräftar du att du uppmanas att installera Intune-företagsportalen från antingen en annan appbutik eller en Microsoft-webbplats.

8. Installera företagsportalen. Du behöver inte starta företagsportalen eller logga in på företagsportalen.
9. Gå tillbaka till din app och logga in igen om det behövs.
10. Bekräfta att skärmen Få åtkomst visas som visas. Detta anger att SDK:n har hämtat principen för det här kontot.
11. Du uppmanas att ange en PIN-kod för appen. Skapa en PIN-kod.
12. Navigera runt i programmet och försök ta skärmbilder. Med tanke på att SDK:n har en princip bör detta konsekvent blockeras på alla skärmar.
13. Logga ut det hanterade kontot från programmet.
14. Om möjligt utan att logga in, navigera runt i ditt program och försök ta skärmbilder. Nu när kontot har tagits bort ska det inte blockeras.

Det här är ett minsta test för att bekräfta att din app har registrerat kontot korrekt, registrerat motringningen för autentisering och avregistrerat kontot. Utför följande tester för att mer noggrant verifiera hur andra inställningar för appskyddsprinciper ändrar programmets beteende.

Test av dataskydd

Följande tester omfattar specifika dataskyddsinställningar som konfigurerats i appskyddsprincipen. När du ändrar inställningarna för appskyddsprincipen i Microsoft Intune administrationscenter uppdateras inte klienten omedelbart. Se Testa snabbt med ändrad princip om du vill ha tips om hur du kan testa snabbare.

För de här testerna:

1. Installera appen.
2. Installera Intune-företagsportalen.
3. Installera en annan hanterad app, riktad mot samma princip som din app, som kan kopiera och klistra in data (t.ex. Microsoft Office).
4. Installera (eller återanvända) alla ohanterade appar som kan kopiera och klistra in data.
5. Logga in på appen med det testhanterade kontot.
6. Logga in med det andra hanterade testkontot i den andra hanterade appen.

Test av dataöverföring

Dataöverföringsinställningar är en delmängd av dataskyddsfunktionerna för programskyddsprinciper som styr data som anges och avslutas för hanterade appar. De flesta appar som har stöd för att skicka data till eller ta emot data från andra appar har också möjlighet att spara data till och öppna data från lokal lagring eller molnlagring. Om din app har dessa funktioner måste du implementera ytterligare stöd. Mer information finns i Policy för att begränsa dataöverföring mellan appar och enheter eller molnlagringsplatser .

Din app kan aktivt importera data från andra appar, till exempel Outlook bifoga en fil från Microsoft OneDrive. Din app kan också passivt ta emot data från andra appar, till exempel Microsoft Office som öppnar ett dokument från en bifogad Outlook-fil. Principinställningen "ta emot data från andra appar" omfattar båda scenarierna.

För de här testerna:

1. Installera appen.
2. Installera Intune-företagsportalen.
3. Installera en annan hanterad app, riktad mot samma princip som din app, som kan skicka och ta emot data (t.ex. Outlook).
4. Installera (eller återanvända) alla ohanterade appar som kan skicka och ta emot data.
5. Logga in på appen med det testhanterade kontot.
6. Logga in med det andra hanterade testkontot i den andra hanterade appen.

Andra dataskyddsinställningar

Följande dataskyddsinställningar tillämpas inte förrän appen gör ytterligare ändringar. Du behöver inte testa de här inställningarna i det här skedet. Mer information finns i steg 7: Funktioner för appdeltagande .

Test av villkorsstyrd start

Inställningar för villkorsstyrd start är en delmängd av funktionerna i appskyddsprinciper som begränsar åtkomsten till din app baserat på konfigurerbara enhetsomfattande eller appspecifika kriterier. De här inställningarna omfattar både villkor (t.ex. "lägsta version av operativsystemet") och åtgärder (t.ex. blockering av åtkomst). Åtgärder för villkorlig start kan vara antingen:

• Varna: slutanvändaren ser en varningsdialogruta när enheten eller appen inte uppfyller villkoren. De har fortfarande åtkomst till alla appdata.
• Blockera åtkomst: slutanvändaren ser en varningsdialogruta när enheten eller appen inte uppfyller villkoren. De tillåts inte att komma åt appen och komma åt appdata förrän de antingen uppfyller villkoren eller tar bort det hanterade kontot från appen.
• Rensa data: alla företagsdata som är kopplade till det hanterade kontot rensas om enheten eller appen inte uppfyller villkoren. Användaren har inte möjlighet att uppfylla villkoren innan data tas bort.

Vissa inställningar för villkorsstyrd start kan konfigureras med flera värden och åtgärder. Till exempel:

• Lägsta OS-version, värdet "10.0", åtgärden inställd på "Varna".
• Lägsta operativsystemversion, värdet "9.0", åtgärden är inställd på "Blockera åtkomst"
• Lägsta operativsystemversion, värdet 8.0, åtgärden är inställd på "Rensa data".

Genom att slutföra integreringsstegen i det här steget har din app nu stöd för alla funktioner för villkorlig start. Bekanta dig med funktionen för villkorlig start genom att ändra principobjekt så att testenheten:

• Godkänner alla konfigurerade inställningar för villkorsstyrd start.
• Misslyckas med en konfigurerad inställning för villkorsstyrd start som angetts till åtgärden "Varna".
• Misslyckas med en konfigurerad inställning för villkorsstyrd start som angetts till åtgärden "Blockera åtkomst".
• Misslyckas med en konfigurerad inställning för villkorsstyrd start som är inställd på åtgärden Rensa data.

Felsökning

Felsökning av test av First Policy Application

Om du följer stegen i First Policy Application Test ovan kan du stöta på följande oväntade problem:

När jag har loggat in med ett hanterat konto uppmanas jag inte att installera företagsportalen (steg 7)

Besök först administrationscentret för Intune och dubbelkolla att appskyddsprincipen är riktad mot ditt testkonto.

För det andra, dubbelkolla din källkod för anrop till registerAccountForMAM och implementering av MAMServiceAuthenticationCallback. Om den förstnämnda inte anropas vid rätt tidpunkt och/eller om den senare inte tillhandahöll en giltig token korrekt visas inte uppmaningen i Företagsportal.

Slutligen letar du antingen i loggarna (eller felsökning) efter registreringsresultatkoden eller anropar getRegisteredAccountStatus kontot uttryckligen. Koder som NOT_LICENSED kan indikera konfigurationsproblem med testkontot.

Jag såg inte skärmen Få åtkomst efter inloggning (steg 10)

Om företagsportalen inte har installerats tidigare kan du behöva återuppta eller starta om programmet helt för att se skärmen Få åtkomst och få principen korrekt tillämpad. Det här är ett förväntat resultat baserat på hur SDK-integrerade appar utnyttjar kod i företagsportalen.

Om du fortfarande inte ser skärmen Få åtkomst, även efter att du har startat om appen och loggat in igen, kan SDK:n misslyckas med att antingen registrera kontot eller hämta principen för kontot. Dubbelkolla källkodens implementering av MAMServiceAuthenticationCallback.

Jag ser inte skärmen för att ange eller ange en PIN-kod för en app efter inloggning (steg 11)

Finns det andra SDK-integrerade program på testenheten? App-PIN-koden delas mellan alla hanterade appar och SDK har en global timer för att förhindra att slutanvändare uppmanas att ange PIN-koden vid varje hanterad appstart eller återupptagning.

Annars går du till Intune administrationscenter och dubbelkollar att appskyddsprincipen har appskyddskoden aktiverad och är riktad mot ditt testkonto.

Som en sista utväg återställs PIN-kodstimern om du startar om enheten. Om PIN-kodsskärmen inte visas när du har startat om enheten är den troligen inte korrekt konfigurerad i principen.

Jag såg skärmen Få åtkomst, men skärmbilder är fortfarande tillåtna (steg 12)

Medan principen hämtas tillämpas fel princip. Besök först administrationscentret för Intune och dubbelkontrollera att appskyddsprincipen inaktiverar skärmbilder och är riktad till ditt testkonto. Därefter använder du diagnostikkonsolen (beskrivs ovan) för att kontrollera principen som har tagits ned för din app. Om båda principerna bekräftar att skärmbilder ska blockeras kontrollerar du konfigurationen av plugin-programmet för Gradle-versionen för att säkerställa att MAM-ersättningar görs.

Min app verkar krascha eller stängas efter att jag loggat ut (steg 13)

När du avregistrerar ett konto som tidigare har registrerats och vars princip har tillämpats rensas data som är associerade med det kontot av SDK:n. Appprocessen avslutas förväntat.

Skärmbilder blockeras fortfarande även efter att jag loggat ut (steg 14)

Dubbelkolla källkoden för samtal till unregisterAccountForMAM(). Om principen fortfarande tillämpas efter utloggning är det troligt att kontot inte har avregistrerats och avregistrerats korrekt.

Felsökning av dataskyddstest

Om du följer stegen i dataskyddstesterna ovan kan du stöta på följande oväntade problem:

Min app tar inte emot eller tillämpar inga principer

Bekräfta först att appskyddsprincipen är riktad mot en grupp som innehåller testkontot. Mer information finns i Så här verifierar du konfigurationen av appskyddsprincipen i Microsoft Intune.

Kontrollera sedan klientdiagnostikinformationen för att bekräfta att SDK har tagit emot den konfigurerade principen. Om så inte är fallet kontrollerar du appens implementering av MAMServiceAuthenticationCallback och anropar till registerAccountForMAM. Kontrollera även loggar eller felsökning för att verifiera MAMEnrollmentManager.Result.

Min app kan dela data till en ohanterad app

Bekräfta att "Skicka organisationsdata till andra appar" är inställt på "Principhanterade appar". Kontrollera administrationscentret för Microsoft Intune för att bekräfta att principen är korrekt konfigurerad och riktad. Kontrollera klientdiagnostikinformationen för att bekräfta att SDK har tagit emot den konfigurerade principen.

Om principen har konfigurerats och hämtats korrekt kontrollerar du om några principer tillämpas: Min app tar inte emot eller tillämpar inga principer.

Min app kan inte dela data med en annan hanterad app

Bekräfta inställningarna för appskyddsprinciper som är riktade till både din app och den andra hanterade appen. Vi rekommenderar att samma princip gäller för båda apparna. Principen för din app ska ha "Skicka organisationsdata till andra appar" inställt på "Principhanterade appar". Kontrollera policyn som är inriktad på den andra appen. om "Ta emot data från andra appar" är inställt på "Ingen" förväntas detta beteende.

Min app kan ta emot data från en ohanterad app

Bekräfta att "Ta emot data från andra appar" är inställt på "Principhanterade appar". Kontrollera administrationscentret för Microsoft Intune för att bekräfta att principen är korrekt konfigurerad och riktad. Kontrollera klientdiagnostikinformationen för att bekräfta att SDK har tagit emot den konfigurerade principen.

Om principen har konfigurerats och hämtats korrekt kontrollerar du om några principer tillämpas: Min app tar inte emot eller tillämpar inga principer.

Min app kan inte ta emot data från någon annan hanterad app

Bekräfta inställningarna för appskyddsprinciper som är riktade till både din app och den andra hanterade appen. Vi rekommenderar att samma princip gäller för båda apparna. Principen som är avsedd för din app ska ha "Ta emot data från andra appar" inställt på "Principhanterade appar". Kontrollera policyn som är inriktad på den andra appen. Om "Skicka organisationsdata till andra appar" är inställt på "Ingen" förväntas detta beteende.

Nästa steg

När du har uppfyllt alla avslutsvillkor ovan är din app nu integrerad som en enda identitet och kan tillämpa alla grundläggande appskyddsprinciper. De efterföljande avsnitten, steg 5: Flera identiteter, steg 6: App Configuration och steg 7: Funktioner för appdeltagande kan vara nödvändiga eller inte, beroende på vilket stöd för appskyddsprincipen du vill ha. Om du är osäker på om något av dessa avsnitt gäller för din app går du till viktiga beslut för SDK-integrering.