La piattaforma Android consente ai dispositivi di avere lavoro profili (a volte indicati come profili gestiti). È controllato un profilo di lavoro da un amministratore IT e la funzionalità a sua disposizione viene impostata separatamente funzionalità del profilo principale dell'utente. Questo approccio consente alle organizzazioni di controllare l'ambiente in cui sono in esecuzione app e dati specifici dell'azienda sul dispositivo di un utente; continuando a consentire agli utenti di utilizzare le proprie app e i propri profili personali.
Questa lezione mostra come modificare l'applicazione in modo che funzioni in modo affidabile su un dispositivo con un profilo di lavoro. Non devi fare nulla che vanno oltre le normali best practice di sviluppo delle app. Tuttavia, alcuni dei migliori diventano particolarmente importanti sui dispositivi con profili di lavoro. Questo documento evidenzia i problemi di cui devi essere a conoscenza.
Panoramica
Gli utenti spesso preferiscono utilizzare i propri dispositivi personali in un ambiente aziendale. Questo questa situazione può presentare alle organizzazioni un dilemma. Se l'utente può utilizzare i propri dispositivo, l'organizzazione deve preoccuparsi che le informazioni riservate (come i email e contatti) si trovano su un dispositivo non controllato dall'organizzazione.
Per far fronte a questa situazione, Android 5.0 (livello API 21) consente alle organizzazioni di Configurare profili di lavoro. Se un dispositivo ha un profilo di lavoro, l' sono sotto il controllo dell'amministratore IT. La L'amministratore IT può scegliere quali app sono consentite per quel profilo e può controllare solo quali funzioni del dispositivo sono disponibili per il profilo.
Se un dispositivo ha un profilo di lavoro ci sono implicazioni per le app in esecuzione sul dispositivo, indipendentemente dal profilo in cui è eseguita l'app:
- Per impostazione predefinita, la maggior parte degli intent non passa da un profilo all'altro. Se un'app in esecuzione su un profilo attiva un intent, ma non esiste un gestore per l'intent profilo e l'intent non può passare all'altro profilo. a causa delle limitazioni del profilo, la richiesta non va a buon fine e l'app potrebbe arrestarsi in modo imprevisto.
- L'amministratore IT del profilo può limitare le app di sistema disponibili nella profilo di lavoro. Questa restrizione può anche comportare l'assenza di un gestore per alcuni intent comuni sul profilo di lavoro.
- Poiché il profilo personale e quello di lavoro hanno aree di archiviazione separate, l'URI del file valido in un profilo non lo è nell'altro. Qualsiasi l'intent attivato in un profilo potrebbe essere gestito nell'altro (a seconda del profilo impostazioni), quindi non è sicuro allegare gli URI dei file agli intent.
Impedisci intent non riusciti
Su un dispositivo con un profilo di lavoro, esistono limitazioni relative all'eventuale presenza di intent possono passare da un profilo all'altro. Nella maggior parte dei casi, quando viene attivato un intent disattivata, viene gestita nello stesso profilo in cui viene attivata. Se non è presente alcun gestore per l'intent su quel profilo, l'intent non viene gestito e l'app che l'hanno attivato potrebbero arrestarsi inaspettatamente, anche se è presente un gestore l'intent nell'altro profilo.
L'amministratore del profilo può scegliere quali intent possono passare da un profilo all'altro. Poiché l'amministratore IT questa decisione, non c'è modo per te di sapere in anticipo quali intent sono autorizzati a superare questo confine. La L'amministratore IT imposta questo criterio ed è libero di modificarlo in qualsiasi momento.
Prima che l'app inizi un'attività, devi verificare che sia presente una
risoluzione adeguata. Tu
può verificare che esista una risoluzione accettabile chiamando Intent.resolveActivity()
. In caso contrario,
per risolvere l'intent, il metodo restituisce
null
. Se il metodo restituisce un valore diverso da null, esiste almeno un modo per
risolvere l'intento ed è sicuro disattivare l'intento. In questo caso,
l'intent potrebbe essere risolvibile
perché esiste un gestore nel profilo corrente o perché l'intent
possono passare a un gestore sull'altro profilo. (Per ulteriori informazioni
risolvere gli intenti, consulta Intent comuni.
Ad esempio, se la tua app deve impostare i timer, deve controllare che
esiste un gestore valido per l'intent ACTION_SET_TIMER
. Se l'app non può essere risolta
l'intento, dovrebbe intraprendere un'azione appropriata (ad esempio, mostrare un errore
).
Kotlin
fun startTimer(message: String, seconds: Int) { // Build the "set timer" intent val timerIntent = Intent(AlarmClock.ACTION_SET_TIMER).apply { putExtra(AlarmClock.EXTRA_MESSAGE, message) putExtra(AlarmClock.EXTRA_LENGTH, seconds) putExtra(AlarmClock.EXTRA_SKIP_UI, true) } // Check if there's a handler for the intent if (timerIntent.resolveActivity(packageManager) == null) { // Can't resolve the intent! Fail this operation cleanly // (perhaps by showing an error message) } else { // Intent resolves, it's safe to fire it off startActivity(timerIntent) } }
Java
public void startTimer(String message, int seconds) { // Build the "set timer" intent Intent timerIntent = new Intent(AlarmClock.ACTION_SET_TIMER) .putExtra(AlarmClock.EXTRA_MESSAGE, message) .putExtra(AlarmClock.EXTRA_LENGTH, seconds) .putExtra(AlarmClock.EXTRA_SKIP_UI, true); // Check if there's a handler for the intent if (timerIntent.resolveActivity(getPackageManager()) == null) { // Can't resolve the intent! Fail this operation cleanly // (perhaps by showing an error message) } else { // Intent resolves, it's safe to fire it off startActivity(timerIntent); } }
Condividi file tra profili
A volte un'app deve fornire ad altre app l'accesso ai propri file. Ad esempio, un'app Galleria immagini potrebbe voler condividere le proprie immagini con editor. In genere, esistono due modi in cui condividere un file: con un file URI o URI contenuto.
Un URI del file inizia con il prefisso file:
, seguito dal
percorso assoluto del file nello spazio di archiviazione del dispositivo. Tuttavia, poiché
il profilo di lavoro e il profilo personale usano aree di archiviazione separate, un URI del file
che è valido in un profilo, non lo è nell'altro. Questa situazione
significa che se
allegare un URI di file a un intent; l'intent viene gestito nell'altro profilo,
il gestore non riesce ad accedere al file.
Dovrà invece condividere i file con gli URI dei contenuti. URI contenuti
a identificare il file in modo più sicuro e condivisibile. L'URI dei contenuti contiene
il percorso del file, ma anche l'autorità che fornisce il file e un numero ID
identificando il file. Puoi generare un Content ID per qualsiasi file utilizzando un'interfaccia
FileProvider
. Puoi quindi condividere i contenuti
ID con altre app (anche sull'altro profilo). Il destinatario può utilizzare
Content ID per ottenere l'accesso al file effettivo.
Ad esempio, ecco come ottenere l'URI dei contenuti per un file specifico URI:
Kotlin
// Open File object from its file URI val fileToShare = File(fileUriToShare) val contentUriToShare: Uri = FileProvider.getUriForFile( context, "com.example.myapp.fileprovider", fileToShare )
Java
// Open File object from its file URI File fileToShare = new File(fileUriToShare); Uri contentUriToShare = FileProvider.getUriForFile(getContext(), "com.example.myapp.fileprovider", fileToShare);
Quando chiami il metodo getUriForFile()
,
devi includere l'autorità del fornitore del file (in questo esempio,
"com.example.myapp.fileprovider"
), che è specificato nel
<provider>
:
dell'app.
Per ulteriori informazioni sulla condivisione di file con URI dei contenuti, consulta
Condivisione
File.
Ascoltare le notifiche
Un'app in genere fornisce
NotificationListenerService
sottoclasse in
Ricevere callback dal sistema sulle modifiche alle notifiche. Dispositivi con
I profili di lavoro potrebbero influire sul funzionamento di NotificationListenerService
con la tua app.
In un profilo di lavoro
Non puoi usare NotificationListenerService
di un'app
in esecuzione nel profilo di lavoro. Quando l'app è in esecuzione in un profilo di lavoro,
ignora i valori NotificationListenerService
dell'app. Tuttavia,
le app in esecuzione nel profilo personale possono ascoltare le notifiche.
In un profilo personale
Quando la tua app viene eseguita nel profilo personale, potresti non ricevere notifiche
per le app eseguite nel profilo di lavoro. Per impostazione predefinita, tutte le app del profilo personale
ricevi callback, ma un amministratore IT può inserire nella lista consentita uno o più profili personali
app a cui consentono di ascoltare le modifiche alle notifiche. Il sistema blocca quindi
app non incluse nella lista consentita. In Android 8.0 (livello API 26) o versioni successive, un criterio relativo ai dispositivi
che gestisce un profilo di lavoro potrebbe impedire all'app di ascoltare
alle notifiche del profilo di lavoro utilizzando DevicePolicyManager
metodo
setPermittedCrossProfileNotificationListeners()
.
La tua app continua a ricevere callback per le notifiche pubblicate nell'account personale
profilo.
Testa la tua app per verificarne la compatibilità con i profili di lavoro
Devi testare l'app in un ambiente del profilo di lavoro per individua i problemi che causano il mancato funzionamento dell'app su un dispositivo con profili di lavoro. In particolare, il test su un dispositivo con profilo di lavoro è una buona per assicurarti che l'app gestisca correttamente gli intent, ovvero non attivare intent che non possono essere gestiti, non collegare URI che non funzionano in più profili attiva.
Abbiamo fornito un'app di esempio, TestDPC, che puoi utilizzare per configurare un profilo di lavoro su un dispositivo Android con Android 5.0 (livello API 21) e versioni successive. Questa app offre un modo semplice per eseguire test la tua app in un ambiente di profilo di lavoro. Puoi utilizzare questa app anche per configurare il profilo di lavoro nel seguente modo:
- Specifica quali app predefinite sono disponibili nella profilo
- Configura quali intent possono essere trasferiti da un profilo a l'altro
Se installi manualmente un'app tramite un cavo USB su un dispositivo dotato di profilo di lavoro, l'app è installata sul profilo personale e profilo. Una volta installata l'app, puoi testarla nel le seguenti condizioni:
- Se un intent viene normalmente gestito da un'app predefinita (ad esempio, l'app Fotocamera), prova a disattivare l'app predefinita sul profilo di lavoro e e verifica che l'app li gestisca in modo appropriato.
- Se attivi un intent che si aspetta che venga gestito da un'altra app, prova
attivare e disattivare l'autorizzazione dell'intent da trasferire da un profilo a
un'altra. Verifica che l'app funzioni correttamente in entrambe le circostanze. Se
per intent non può passare da un profilo all'altro, verificare il comportamento dell'app
quando nel profilo dell'app è presente un gestore idoneo e quando non è presente.
Ad esempio, se la tua app attiva un intent correlato alla mappa, prova a procedere in uno dei seguenti modi
scenari aggiuntivi:
- Il dispositivo consente il passaggio da un profilo all'altro degli intent di mappa. c'è un gestore adatto sull'altro profilo (il profilo a cui l'app in esecuzione)
- Il dispositivo non consente di passare da un profilo all'altro gli intent delle mappe, ma sia un gestore adatto nel profilo dell'app
- Il dispositivo non consente l'incrocio di profili con intenti di mappa e non è un gestore adatto per gli intent di mappa sul profilo del dispositivo
- Se alleghi contenuti a un intent, verifica che quest'ultimo si comporti correttamente sia quando viene gestita nel profilo dell'app, sia quando si incrocia profili.
Eseguire test sui profili di lavoro: suggerimenti utili
Esistono alcuni suggerimenti che potrebbero esserti utili durante i test su una dispositivo del profilo di lavoro.
- Come indicato, quando carichi un'app tramite sideload su un dispositivo del profilo di lavoro, installato su entrambi i profili. Se vuoi, puoi eliminare l'app da un profilo e lasciarla sull'altro.
- La maggior parte dei comandi di Gestione attività disponibili nella shell di Android Debug Bridge (adb)
supporta il flag
--user
, che ti consente di specificare quale utente eseguire come. Se specifichi un utente, puoi scegliere se eseguire l'esecuzione come utente principale non gestito o un profilo di lavoro. Per ulteriori informazioni, consulta ADB di Cloud Shell. - Per trovare gli utenti attivi su un dispositivo, utilizza lo strumento
Comando
list users
. Il primo numero nella stringa di output è ID utente, che puoi utilizzare con il flag--user
. Per ulteriori informazioni consulta la sezione Shell ADB Comandi.
Ad esempio, per trovare gli utenti su un dispositivo, dovresti eseguire questo comando:
$ adb shell pm list users UserInfo{0:Drew:13} running UserInfo{10:Work profile:30} running
In questo caso, l'utente principale ("Drew") ha l'ID utente 0 e del profilo di lavoro ha l'ID utente 10. Per eseguire un'app nel profilo di lavoro, devi utilizzeresti un comando come questo:
$ adb shell am start --user 10 \ -n "com.example.myapp/com.example.myapp.testactivity" \ -a android.intent.action.MAIN -c android.intent.category.LAUNCHER