La plataforma de Android permite que los dispositivos tengan trabajo perfiles (a veces denominados perfiles administrados). Se controla un perfil de trabajo por un administrador de TI y la funcionalidad disponible para ella se configura por separado del funcionalidad del perfil principal del usuario. Este enfoque permite a las organizaciones controlar el entorno en el que se ejecutan apps y datos específicos de la empresa en el dispositivo de un usuario sin dejar de permitir que los usuarios usen sus apps y perfiles personales.
En esta lección, se muestra cómo modificar tu aplicación para que funcione de manera confiable en un dispositivo con un perfil de trabajo. No es necesario que hagas nada. además de las prácticas recomendadas comunes para el desarrollo de aplicaciones. Sin embargo, algunos de estos mejores prácticas cada vez son más importantes en dispositivos con perfiles de trabajo. Esta en el que se destacan los problemas que debes tener en cuenta.
Descripción general
A menudo, los usuarios quieren usar sus dispositivos personales en un entorno empresarial. Esta puede plantear un dilema a las organizaciones. Si el usuario puede usar sus propios dispositivo, la organización tiene que preocuparse por que la información confidencial (como los correos electrónicos y contactos) están en un dispositivo que la organización no controla.
Para abordar esta situación, Android 5.0 (nivel de API 21) permite a las organizaciones configurar perfiles de trabajo Si un dispositivo tiene un perfil de trabajo, el perfil están bajo el control del administrador de TI. El El administrador de TI puede elegir qué apps están permitidas para ese perfil controlar únicamente las funciones del dispositivo que están disponibles en el perfil.
Si un dispositivo tiene un perfil de trabajo, las apps pueden tener consecuencias que se ejecuta en el dispositivo, independientemente del perfil en el que se ejecute la app:
- De forma predeterminada, la mayoría de los intents no pasan de un perfil a otro. Si un que una app que se ejecuta en el perfil activa un intent, no hay controladores para el intent ese perfil, y el intent no puede cruzarse al otro perfil debido a restricciones de perfiles, la solicitud falla y la app puede cerrarse inesperadamente.
- El administrador de TI del perfil puede limitar las apps del sistema que están disponibles en la perfil de trabajo. Esta restricción también puede hacer que no haya controladores algunos intents comunes en el perfil de trabajo.
- Dado que los perfiles personal y de trabajo tienen áreas de almacenamiento independientes, se puede El URI de archivo válido en un perfil no lo es en el otro. Cualquiera el intent activado en un perfil puede controlarse en el otro (según la configuración ), por lo que no es seguro adjuntar URI de archivo a los intents.
Evita los intents con errores
En un dispositivo con un perfil de trabajo, existen restricciones sobre si los intents pueden pasar de un perfil a otro. En la mayoría de los casos, cuando se activa un intent se controla en el mismo perfil en el que se activa. Si no hay un controlador para el intent en ese perfil, no se controla el intent y la app que la activó puede apagarse de forma inesperada, incluso si existe un controlador para en el otro perfil.
El administrador de perfiles puede elegir qué intents pueden cruzar de un perfil a otro. Dado que el administrador de TI esta decisión, no hay forma de que para saber de antemano qué intents pueden cruzar este límite. El El administrador de TI establece esta política y puede cambiarla en cualquier momento.
Antes de que tu app inicie una actividad, debes verificar que haya un
resolución adecuada. Tú
puedes verificar que haya una resolución aceptable llamando a Intent.resolveActivity(). Si no hay
de resolver el intent, el método devuelve
null Si el método muestra un valor no nulo, hay al menos una manera de
resuelve el intent, y es seguro activarlo. En este caso, el
intent podría resolverse
porque hay un controlador en el perfil actual, o porque el intent es
puede cruzar a un controlador en el otro perfil. (Para obtener más información
resolver intents, consulta Intents comunes).
Por ejemplo, si la app necesita establecer temporizadores, deberá comprobar que
hay un controlador válido para el intent ACTION_SET_TIMER. Qué hacer si la app no puede resolverse
el intent, debe tomar una acción adecuada (como mostrar un error
mensaje).
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);
}
}
Cómo compartir archivos entre perfiles
A veces, una app debe proporcionarles a otras apps acceso a sus propios archivos. Por ejemplo, una app de galería de imágenes podría compartir sus imágenes con imágenes editores. Generalmente, puedes compartir un archivo de dos maneras: con un archivo URI o un URI de contenido.
Un URI de archivo comienza con el prefijo file:, seguido del
absoluta del archivo en el almacenamiento del dispositivo. Sin embargo, debido a que el
el perfil de trabajo y el personal usan áreas de almacenamiento separadas, un URI de archivo
que es válido en un perfil no lo es en el otro. Esta situación
significa que, si
adjuntar un URI de archivo a un intent, y este se controla en el otro perfil
el controlador no puede acceder al archivo.
En su lugar, debes compartir archivos con URI de contenido. URI de contenido
identificar el archivo de forma más segura y compartible. El URI de contenido incluye
la ruta de acceso al archivo, sino también la autoridad que proporciona el archivo y un número de ID
identificar el archivo. Puedes generar un ID de contenido para cualquier archivo usando una
FileProvider Luego, puedes compartir ese contenido
con otras apps (incluso en el otro perfil). El destinatario puede usar el
Content ID para obtener acceso al archivo.
Por ejemplo, a continuación, se muestra cómo obtener el URI de contenido de un archivo específico 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);
Cuando llamas al método getUriForFile(),
debes incluir la autoridad del proveedor de archivos (en este ejemplo,
"com.example.myapp.fileprovider"), que se especifica en el
<provider>
del manifiesto de la app.
Para obtener más información sobre cómo compartir archivos con URI de contenido, consulta
Uso compartido
Archivos
Cómo detectar notificaciones
Por lo general, una app proporciona una
Subclase NotificationListenerService a
recibir devoluciones de llamada del sistema sobre cambios en las notificaciones. Dispositivos con
los perfiles de trabajo podrían afectar el funcionamiento de NotificationListenerService
con tu app.
En un perfil de trabajo
No puedes usar un NotificationListenerService desde una app
que se ejecuta en el perfil de trabajo. Cuando tu app se ejecuta en un perfil de trabajo, la
sistema ignora la NotificationListenerService de tu app. Sin embargo,
Las apps que se ejecutan en el perfil personal pueden escuchar las notificaciones.
En un perfil personal
Cuando tu app se ejecuta en el perfil personal, es posible que no recibas notificaciones
para las apps que se ejecutan en el perfil de trabajo. De forma predeterminada, todas las aplicaciones del perfil personal
pero un administrador de TI puede incluir uno o más perfiles personales
a las que les permiten detectar
cambios en las notificaciones. Luego, el sistema bloquea
que no están incluidas en la lista de entidades permitidas. En Android 8.0 (nivel de API 26) o versiones posteriores, se aplica una política de dispositivo
(DPC) que administra un perfil de trabajo podría impedir que tu app escuche
a las notificaciones del perfil de trabajo con el DevicePolicyManager
método
setPermittedCrossProfileNotificationListeners()
Tu app seguirá recibiendo devoluciones de llamada sobre notificaciones publicadas en la página
perfil.
Prueba la compatibilidad de tu app con los perfiles de trabajo
Debes probar tu app en un entorno de perfil de trabajo para detectar problemas que harían que tu app fallara en un dispositivo con perfiles de trabajo. En particular, probar en un dispositivo con perfil de trabajo es una buena de manera correcta para garantizar que tu app administre los intents correctamente, es decir, no se adjuntan URI que no funcionan con el perfil sincronizado, por lo que .
Proporcionamos una app de ejemplo, TestDPC, que puedes usar para configurar un perfil de trabajo en un dispositivo Android que ejecute Android 5.0 (nivel de API 21) y versiones posteriores Esta app te ofrece una manera sencilla de probar tu aplicación en un entorno de perfil de trabajo. También puedes usar esta app para configura el perfil de trabajo de la siguiente manera:
- Especifica qué apps predeterminadas están disponibles en la instancia perfil
- Configura los intents que pueden cruzarse de un perfil a el otro
Si instalas manualmente una app a través de un cable USB a un dispositivo que tiene perfil de trabajo, la app se instalará tanto en el personal como en el de trabajo perfil. Una vez que instales la app, podrás probarla en la siguientes condiciones:
- Si una app predeterminada controlaría un intent normalmente (por ejemplo, la app de la cámara), inhabilita la app predeterminada en el perfil de trabajo y verificar que la app lo maneje adecuadamente.
- Si activas un intent y esperas que lo controle otra app, prueba
habilitar e inhabilitar el permiso de ese intent para cruzar de un perfil a
con el otro. Verifica que la app se comporte correctamente en ambas circunstancias. Si el botón
no puede cruzarse entre perfiles; verifica el comportamiento de la app
cuando hay un controlador adecuado en el perfil de la app y cuando no lo hay.
Por ejemplo, si tu app activa un intent relacionado con el mapa, prueba cada una de las siguientes opciones:
diferentes:
- El dispositivo permite que los intents de mapa pasen de un perfil al otro. hay un controlador adecuado en el otro perfil (el perfil al que la app no está se está ejecutando)
- El dispositivo no permite que los intents de mapas pasen de un perfil a otro, pero hay es un controlador adecuado en el perfil de la app
- El dispositivo no permite que los intents de mapa crucen un perfil. no es un controlador adecuado para intents de mapa en el perfil del dispositivo.
- Si adjuntas contenido a un intent, verifica que este se comporte correctamente tanto cuando se controla en el perfil de la app, como cuando se combina perfiles.
Pruebas en perfiles de trabajo: sugerencias y trucos
Hay algunos trucos que pueden resultarte útiles para realizar pruebas en un dispositivo de perfil de trabajo.
- Como se mencionó, cuando transfieres una app en un dispositivo con perfil de trabajo, instalada en ambos perfiles. Si lo deseas, puedes borrar la app de un perfil y déjalo por el otro.
- La mayoría de los comandos del administrador de actividades disponibles en el shell de Android Debug Bridge (adb)
admite la marca
--user, que te permite especificar qué usuario ejecutar como Cuando especificas un usuario, puedes elegir si se ejecutará como el usuario principal no administrado o tu perfil de trabajo. Para obtener más información, consulta ADB Comandos de shell. - Para buscar los usuarios activos en un dispositivo, usa el parámetro
Comando
list users. El primer número de la cadena de salida es ID de usuario, que puedes usar con la marca--user. Para ver más consulta ADB Shell Comandos
Por ejemplo, para encontrar a los usuarios en un dispositivo, podrías ejecutar este comando:
$ adb shell pm list users
UserInfo{0:Drew:13} running
UserInfo{10:Work profile:30} running
En este caso, el usuario principal ("Drew") tiene el ID de usuario 0 y el de trabajo tiene el ID de usuario 10. Para ejecutar una app en el perfil de trabajo, usaría un comando como el siguiente:
$ adb shell am start --user 10 \ -n "com.example.myapp/com.example.myapp.testactivity" \ -a android.intent.action.MAIN -c android.intent.category.LAUNCHER