Le funzionalità aziendali di Android offrono alle organizzazioni un ambiente sicuro, flessibile piattaforma di mobilità Android unificata, che combina dispositivi, applicazioni e la loro gestione. Le app Android sono compatibili con le funzionalità aziendali di Android per impostazione predefinita. Esistono però delle funzionalità aggiuntive che puoi utilizzare la tua app funziona al meglio sui dispositivi Android gestiti:
- Compatibilità del profilo di lavoro: modifica il tuo Android. affinché funzioni al meglio su un dispositivo gestito.
- Configurazioni gestite: modifica per consentire agli amministratori IT di specificare impostazioni delle app.
- Dispositivi dedicati: ottimizza il tuo per poter essere implementata su un dispositivo Android come kiosk.
- Single Sign-On (SSO): semplifica il processo di accesso per gli utenti che accedono a diverse app sul proprio dispositivo Android gestito.
Prerequisiti
- Hai creato un'app per Android.
- Ora puoi modificare la tua app in modo che funzioni al meglio per le organizzazioni.
- Versione minima: Android 5.0 Lollipop Versione consigliata: Android 6.0 Marshmallow e versioni successive.
Nota: le funzionalità aziendali di Android sono integrate nella maggior parte dei dispositivi Android 5.0; mentre Android 6.0 e versioni successive offre funzionalità aggiuntive, soprattutto per quanto riguarda i dispositivi dedicati.
Profili di lavoro
Puoi gestire le applicazioni e i dati aziendali di un utente tramite una profilo di lavoro. Un profilo di lavoro è un profilo aziendale gestito associate all'account utente principale su un dispositivo Android. R il profilo di lavoro isola in modo sicuro app e dati di lavoro dalle app personali e dati. Questo profilo di lavoro si trova in un contenitore separato dal profilo personale controllato dall'utente. Questi profili separati consentono alle organizzazioni di gestire i dati aziendali di loro interesse, lascia sotto il controllo dell'utente tutto ciò che si trova sul dispositivo dell'utente. Per un approfondimento sulle best practice, consulta Profili di lavoro guida. Di seguito è riportata una panoramica di queste best practice.
Funzionalità principali di un profilo di lavoro
- Profilo separato e sicuro
- Versione gestita di Google Play per la distribuzione di applicazioni
- Separa applicazioni di lavoro con badge
- Funzionalità di gestione solo del profilo controllate da un amministratore
Vantaggi del profilo di lavoro su Android 5.0 e versioni successive
- Crittografia completa del dispositivo
- Un solo APK (Android Application Package) per entrambi i profili quando sul dispositivo sono presenti un profilo personale e un profilo di lavoro
- Il controller dei criteri dei dispositivi (DPC) è limitato al profilo di lavoro
- Amministrazione dispositivo tramite Classe DevicePolicyManager
Considerazioni sui profili di lavoro
- Il sistema Android impedisce gli intent da più profili e gli amministratori IT possono Attivare o disattivare le app di sistema.
- Un percorso file (Uniform Resource Identifier [URI]) che sia valido su un profilo potrebbe non essere valido sull'altro.
Impedisci che gli intent presentino errori tra i profili
È difficile sapere quali intenzioni si possono incontrare da un profilo all'altro
quali vengono bloccate. L'unico modo per saperlo con certezza è effettuare dei test.
Prima che l'app inizi un'attività, devi verificare che
viene risolta chiamando
Intent.resolveActivity()
- Se restituisce
null
, la richiesta non viene risolta. - Se restituisce un risultato, significa che l'intent si risolve, ed è sicuro inviare l'intent.
Nota: per istruzioni dettagliate sui test, consulta Impedisci gli intent non riusciti.
Condividi file tra profili
Alcuni sviluppatori utilizzano gli URI per contrassegnare i percorsi dei file in Android. Tuttavia, poiché ci sono file system separati quando è presente un profilo di lavoro, consiglia:
Usa: URI contenuti |
|
Non utilizzare: URI del file |
|
Passaggi successivi: quando l'app supporta profili, testala in un profilo di lavoro. Vedi Testare l'app.
Implementa configurazioni gestite
Le configurazioni gestite sono un insieme di istruzioni che gli amministratori IT possono utilizzare per gestire i dispositivi mobili dei propri utenti in un modo specifico. Queste istruzioni sono universali e utilizzabili con qualsiasi provider EMM, consentendo agli amministratori di configurare da remoto le applicazioni sui smartphone.
Se stai sviluppando app per le aziende o la pubblica amministrazione, potresti aver bisogno per soddisfare le esigenze specifiche del tuo settore. Utilizzo configurazioni gestite, l'amministratore IT può specificare impostazioni e applicare criteri per le app Android dei propri utenti; della esempio:
- Indica se un'app può sincronizzare i dati tramite rete cellulare/3G o solo Wi-Fi
- Consentire o bloccare gli URL su un browser web
- Configurare le impostazioni email di un'app
- Attivare o disattivare la stampa
- Gestisci segnalibri
Best practice per l'implementazione delle configurazioni gestite
L'articolo per configurare le configurazioni gestite è la fonte chiave per informazioni su come creare ed eseguire il deployment e configurazioni gestite. Dopo aver esaminato questa documentazione, consulta di seguito per ulteriori indicazioni.
Al primo avvio dell'app
Non appena avvii un'applicazione, puoi vedere se è gestita
configurazioni sono già impostate per questa app in onStart()
o
onResume()
. Inoltre, puoi scoprire se le tue
se l'applicazione è gestita o non gestita. Ad esempio, se
Resi di getApplicationRestrictions()
:
- Un insieme di restrizioni specifiche per le applicazioni: configurare le configurazioni gestite in modo invisibile all'utente (senza input utente).
- Un bundle vuoto: l'applicazione funziona come non è gestito (ad esempio, il comportamento dell'app ).
- Un bundle con una singola coppia chiave-valore
KEY_RESTRICTIONS_PENDING
impostato su true: la tua l'applicazione viene gestita, ma il DPC non è configurato in modo corretto. Devi bloccare l'utente dalla tua app e indirizzare all'amministratore IT.
Monitora le modifiche alle configurazioni gestite
Gli amministratori IT possono modificare le configurazioni gestite i criteri che desiderano applicare ai propri utenti in qualsiasi momento. A causa di assicurati che la tua app possa accettare nuovi restrizioni per la configurazione gestita come segue:
- Limitazioni di recupero all'avvio: la tua app dovrebbe
chiama
getApplicationRestrictions()
aonStart()
eonResume()
e confrontarli con le limitazioni precedenti per vedere se sono necessarie modifiche. - Ascolta mentre corri: registrazione dinamica
ACTION_APPLICATION_RESTRICTIONS_CHANGED
nel tuo di attività o servizi in esecuzione, dopo aver cercato nuovi limitazioni. Questo intent viene inviato solo agli ascoltatori che registrati dinamicamente e non per gli ascoltatori dichiarati nell'app del file manifest. - Annulla registrazione quando non in esecuzione: in
onPause()
, dovresti annullare la registrazione alla trasmissioneACTION_APPLICATION_RESTRICTIONS_CHANGED
.
Dispositivi dedicati
I dispositivi dedicati sono dispositivi kiosk utilizzati per un singolo scopo, come la segnaletica digitale, la vendita di biglietti chioschi di stampa o registri di pagamento.
Quando un dispositivo Android è configurato come dispositivo dedicato, l'utente vede un'applicazione bloccata sullo schermo senza Home o App recenti per uscire dall'app. I dispositivi dedicati possono anche essere configurati per mostrare di applicazioni, ad esempio un chiosco della biblioteca con un'app per la biblioteca catalogo e un browser web.
Per istruzioni, vedi Dispositivo dedicato.
Configurare il Single Sign-On con le schede personalizzate di Chrome
Gli utenti aziendali spesso hanno più app sul proprio dispositivo e preferiscono effettuare l'accesso una volta sola per accedere a tutte le applicazioni di lavoro. In genere, gli utenti accedono tramite una WebView; Tuttavia, ci sono un paio di motivi per cui non è l'ideale:
- Spesso gli utenti devono accedere più volte con lo stesso account e credenziali. La soluzione WebView spesso non è un singolo singolo dell'accesso (SSO).
- Potrebbero esservi rischi per la sicurezza, tra cui le applicazioni dannose l'ispezione dei cookie o l'inserimento di JavaScript® per accedere ai e credenziali. Anche gli sviluppatori fidati sono a rischio se fanno affidamento SDK di terze parti potenzialmente dannosi.
Una soluzione a entrambi i problemi è autenticare gli utenti utilizzando il browser Schede personalizzate al posto di WebView. Ciò garantisce che l'autenticazione:
- Si verifica in un contesto sicuro (il browser di sistema) in cui l'app host non può esaminare i contenuti.
- Ha uno stato dei cookie condiviso, che assicura che l'utente debba eseguire solo l'accesso. una volta sola.
Requisiti
Le schede personalizzate sono supportate a partire dal livello API 15 (Android 4.0.3). Per utilizzare le schede personalizzate ti serve un browser supportato, ad esempio Chrome. Chrome 45 e versioni successive implementano questa funzionalità come Schede personalizzate di Chrome.
Come faccio a implementare l'accesso SSO con le schede personalizzate?
Google ha reso open source una libreria client OAuth che utilizza le schede, contribuendo al gruppo di lavoro OpenID Connect del OpenID Foundation. Per configurare le schede personalizzate per SSO con libreria AppAuth, consulta documentazione e codice campione su GitHub.
Testare l'app
Dopo aver sviluppato l'app, ti consigliamo di testarla, sia in un profilo di lavoro che dispositivo gestito. Fai riferimento alle istruzioni di seguito.
Usa il DPC di test per testare la tua app per Android
Forniamo l'app DPC di test per aiutare gli sviluppatori Android a testare le loro app in un'azienda completamente gestito di Google Cloud. Utilizzando il DPC di test, puoi impostare i criteri EMM o i valori della configurazione gestita su un dispositivo, come se un'organizzazione gestisse il dispositivo utilizzando un EMM. Per installare il DPC di test su un dispositivo: scegli uno dei seguenti metodi:
- Installa DPC di test da GooglePlay.
- Crea dall'origine su GitHub.
Per ulteriori informazioni su come configurare il DPC di test, consulta le istruzioni riportate di seguito e il Utente DPC di test Google Cloud.
Eseguire il provisioning di un profilo di lavoro
Per testare la tua app in un profilo di lavoro, devi prima eseguire il provisioning di un profilo di lavoro sul dispositivo utilizzando Testa l'app DPC nel seguente modo:
- Installa il DPC di test sul dispositivo.
- In Avvio app di Android, tocca l'icona dell'app Configura DPC di prova.
- Segui le istruzioni sullo schermo.
- Installa l'app sul dispositivo e verificane il funzionamento nel profilo di lavoro.
Android crea un profilo di lavoro e installa una copia del DPC di test nel profilo di lavoro. Utilizzi questo istanza con badge di lavoro del DPC di test per impostare criteri e configurazioni gestite nel profilo di lavoro. A scopri di più sulla configurazione di un profilo di lavoro per lo sviluppo, leggi la guida per gli sviluppatori Profili di lavoro.
Esegui il provisioning di un dispositivo completamente gestito
Le organizzazioni utilizzano dispositivi completamente gestiti perché possono applicare una gamma completa di operazioni di gestione criteri sul dispositivo. Per eseguire il provisioning di un dispositivo completamente gestito, segui questi passaggi:
- Installa il DPC di test sul dispositivo.
- Verifica che sul dispositivo non siano presenti altri utenti o un profilo di lavoro.
- Verifica che non siano presenti account sul dispositivo.
- Esegui il seguente comando Android Debug Bridge (adb) in
il tuo terminale:
adb shell dpm set-device-owner com.afwsamples.testdpc/.DeviceAdminReceiver
- Una volta completato il provisioning del proprietario del dispositivo, puoi testare la tua app su quel dispositivo. Tu deve testare nello specifico come configurazioni gestite e gli intent funzionano su quel dispositivo.
Puoi anche utilizzare altri metodi di provisioning. Consulta la Guida dell'utente per il test del DPC. Per scoprire come l'IT in genere gli amministratori registrano ed eseguono il provisioning dei dispositivi Android, Provisioning dispositivi mobili.
Test end-to-end
Dopo aver completato i test dell'app negli ambienti sopra indicati, ti consigliamo di testare l'app in un ambiente di produzione end-to-end completamente gestito di Google Cloud. Questa procedura include i passaggi che un cliente deve per eseguire il deployment dell'app nell'organizzazione, ad esempio:
- Distribuzione di app tramite Google Play
- Configurazione gestita lato server
- Controllo dei criteri del profilo lato server
Devi accedere a una console EMM per completare l'implementazione end-to-end test. Il modo più semplice per ottenerne uno è richiedere una console di test dal provider EMM. Una volta ottenuto l'accesso, completa queste attività:
- Crea una versione di test dell'applicazione con un new ApplicationId (nuovo ID applicazione).
- Rivendica un dominio Google gestito e vincolalo al tuo provider EMM. Se hai già un dominio di test associato a un EMM, potresti aver bisogno per slegarlo e testarlo con il tuo provider EMM preferito. Consulta il tuo EMM per gli specifici passaggi di svincolo.
- Pubblicare l'applicazione sul canale privato per i propri dominio Google gestito.
- Utilizza la console EMM e l'applicazione EMM per:
- Configura i dispositivi di lavoro.
- Distribuisci la tua applicazione.
- Imposta la configurazione gestita.
- Impostare i criteri relativi ai dispositivi.
Questa procedura varierà in base al tuo provider EMM. Consulta il tuo documentazione dell'EMM per ulteriori dettagli. Complimenti! Hai completato questi passaggi e hai verificato che l'app funziona bene per gli utenti aziendali.