Las apps para Android envían y reciben mensajes de emisión desde el sistema Android y otras apps para Android, de forma similar al patrón de diseño de publicación y suscripción. Por lo general, el sistema y las apps envían transmisiones cuando ocurren ciertos eventos. Por ejemplo, el sistema Android envía transmisiones cuando ocurren diferentes eventos del sistema, como el inicio del sistema o la carga del dispositivo. Las apps también envían transmisiones personalizadas, por ejemplo, para notificar a otras apps sobre algo que podría interesarles (como cuando se descargan datos nuevos).
Las apps pueden registrarse para recibir emisiones específicas. Cuando se envía una emisión, el sistema redirige automáticamente las emisiones a las apps que se suscribieron para recibir ese tipo de emisión particular.
Por lo general, las transmisiones se pueden usar como un sistema de mensajería entre apps y fuera del flujo de usuarios normal. Sin embargo, debes tener cuidado de no abusar de la oportunidad de responder a las emisiones y ejecutar tareas en segundo plano que puedan contribuir a ralentizar el rendimiento del sistema.
Acerca de las emisiones del sistema
El sistema envía transmisiones automáticamente cuando se producen diferentes eventos del sistema, como cuando este activa o desactiva el modo de avión. Todas las apps suscritas reciben estas transmisiones.
El objeto Intent
une el mensaje de emisión. La cadena action
identifica el evento que se produjo, como android.intent.action.AIRPLANE_MODE
. El intent también puede incluir información adicional incluida en su campo adicional.
Por ejemplo, el intent del modo de avión incluye un valor booleano adicional que indica si el modo está activado o no.
Para obtener más información sobre cómo leer los intents y obtener la cadena de acción de un intent, consulta Intents y filtros de intents.
Acciones de transmisión del sistema
Para obtener una lista completa de las acciones de emisión del sistema, consulta el archivo BROADCAST_ACTIONS.TXT
en el SDK de Android. Cada acción de emisión tiene un campo constante asociado. Por ejemplo, el valor de la constante ACTION_AIRPLANE_MODE_CHANGED
es android.intent.action.AIRPLANE_MODE
.
La documentación de cada acción de emisión está disponible en su campo constante asociado.
Cambios en las emisiones del sistema
A medida que la plataforma de Android evoluciona, cambia periódicamente el comportamiento de las emisiones del sistema. Ten en cuenta los siguientes cambios para admitir todas las versiones de Android.
Android 14
Mientras las apps están en un estado almacenado en caché, el sistema optimiza la entrega de transmisiones para el estado del sistema. Por ejemplo, el sistema aplaza las transmisiones del sistema menos importantes, como ACTION_SCREEN_ON
, mientras la app está en un estado almacenado en caché.
Una vez que la app pasa del estado almacenado en caché a un ciclo de vida de proceso activo, el sistema entrega cualquier transmisión diferida.
Las transmisiones importantes que se declaran en el manifiesto quitan temporalmente las apps del estado almacenado en caché para la entrega.
Android 9
A partir de Android 9 (nivel de API 28), la transmisión NETWORK_STATE_CHANGED_ACTION
no recibe información sobre la ubicación del usuario ni los datos de carácter personal.
Si tu app está instalada en un dispositivo que ejecuta Android 9.0 (nivel de API 28) o versiones posteriores, el sistema no incluye SSID, BSSID, información de conexión ni resultados de análisis en las transmisiones de Wi-Fi. Para obtener esta información, llama a getConnectionInfo()
.
Android 8.0
A partir de Android 8.0 (nivel de API 26), el sistema impone restricciones adicionales a los receptores declarados en el manifiesto.
Si tu app se orienta a Android 8.0 o versiones posteriores, no puedes usar el manifiesto para declarar un receptor para la mayoría de las transmisiones implícitas (emisiones que no se orientan específicamente a tu app). Puedes usar un receptor registrado en el contexto cuando el usuario usa tu app de forma activa.
Android 7.0
Android 7.0 (nivel de API 24) y versiones posteriores no envían las siguientes emisiones del sistema:
Además, las apps que se orientan a Android 7.0 y versiones posteriores deben registrar la emisión de CONNECTIVITY_ACTION
con registerReceiver(BroadcastReceiver, IntentFilter)
. La declaración de un receptor en el manifiesto no funciona.
Cómo recibir transmisiones
Las apps pueden recibir transmisiones de dos maneras: mediante receptores registrados en el contexto y mediante receptores declarados en el manifiesto.
Receptores registrados en el contexto
Los receptores registrados en el contexto reciben emisiones siempre que su contexto de registro sea válido. Por lo general, se encuentra entre las llamadas a registerReceiver
y unregisterReceiver
. El contexto de registro también deja de ser válido cuando el sistema destruye el contexto correspondiente. Por ejemplo, si te registras en un contexto Activity
, recibirás emisiones mientras la actividad permanezca activa. Si te registras con el contexto de la aplicación, recibirás transmisiones mientras la app esté en ejecución.
Para registrar un receptor con un contexto, realiza los siguientes pasos:
En el archivo de compilación de nivel de módulo de tu app, incluye la versión 1.9.0 o una posterior de la biblioteca de AndroidX Core:
Groovy
dependencies { def core_version = "1.15.0" // Java language implementation implementation "androidx.core:core:$core_version" // Kotlin implementation "androidx.core:core-ktx:$core_version" // To use RoleManagerCompat implementation "androidx.core:core-role:1.0.0" // To use the Animator APIs implementation "androidx.core:core-animation:1.0.0" // To test the Animator APIs androidTestImplementation "androidx.core:core-animation-testing:1.0.0" // Optional - To enable APIs that query the performance characteristics of GMS devices. implementation "androidx.core:core-performance:1.0.0" // Optional - to use ShortcutManagerCompat to donate shortcuts to be used by Google implementation "androidx.core:core-google-shortcuts:1.1.0" // Optional - to support backwards compatibility of RemoteViews implementation "androidx.core:core-remoteviews:1.1.0" // Optional - APIs for SplashScreen, including compatibility helpers on devices prior Android 12 implementation "androidx.core:core-splashscreen:1.2.0-alpha02" }
Kotlin
dependencies { val core_version = "1.15.0" // Java language implementation implementation("androidx.core:core:$core_version") // Kotlin implementation("androidx.core:core-ktx:$core_version") // To use RoleManagerCompat implementation("androidx.core:core-role:1.0.0") // To use the Animator APIs implementation("androidx.core:core-animation:1.0.0") // To test the Animator APIs androidTestImplementation("androidx.core:core-animation-testing:1.0.0") // Optional - To enable APIs that query the performance characteristics of GMS devices. implementation("androidx.core:core-performance:1.0.0") // Optional - to use ShortcutManagerCompat to donate shortcuts to be used by Google implementation("androidx.core:core-google-shortcuts:1.1.0") // Optional - to support backwards compatibility of RemoteViews implementation("androidx.core:core-remoteviews:1.1.0") // Optional - APIs for SplashScreen, including compatibility helpers on devices prior Android 12 implementation("androidx.core:core-splashscreen:1.2.0-alpha02") }
Crea una instancia de
BroadcastReceiver
:Kotlin
val myBroadcastReceiver = MyBroadcastReceiver()
Java
MyBroadcastReceiver myBroadcastReceiver = new MyBroadcastReceiver();
Crea una instancia de
IntentFilter
:Kotlin
val filter = IntentFilter("com.example.snippets.ACTION_UPDATE_DATA")
Java
IntentFilter filter = new IntentFilter("com.example.snippets.ACTION_UPDATE_DATA");
Elige si el receptor de emisión se debe exportar y ser visible para otras apps en el dispositivo. Si este receptor está escuchando transmisiones enviadas desde el sistema o desde otras apps, incluso otras que sean de tu propiedad, usa la marca
RECEIVER_EXPORTED
. Si, en cambio, este receptor solo escucha las transmisiones que envía tu app, usa la marcaRECEIVER_NOT_EXPORTED
.Kotlin
val listenToBroadcastsFromOtherApps = false val receiverFlags = if (listenToBroadcastsFromOtherApps) { ContextCompat.RECEIVER_EXPORTED } else { ContextCompat.RECEIVER_NOT_EXPORTED }
Java
boolean listenToBroadcastsFromOtherApps = false; int receiverFlags = listenToBroadcastsFromOtherApps ? ContextCompat.RECEIVER_EXPORTED : ContextCompat.RECEIVER_NOT_EXPORTED;
Llama a
registerReceiver()
para registrar el receptor:Kotlin
ContextCompat.registerReceiver(context, myBroadcastReceiver, filter, receiverFlags)
Java
ContextCompat.registerReceiver(context, myBroadcastReceiver, filter, receiverFlags);
Para dejar de recibir transmisiones, llama a
unregisterReceiver(android.content.BroadcastReceiver)
. Asegúrate de anular el registro del receptor cuando ya no lo necesites o el contexto ya no sea válido.
Cancela el registro de tu receptor de emisión
Mientras el receptor de emisión está registrado, contiene una referencia al contexto con el que lo registraste. Esto puede provocar fugas si el alcance registrado del receptor supera el alcance del ciclo de vida de Context. Por ejemplo, esto puede ocurrir cuando registras un receptor en un alcance de actividad, pero te olvidas de anular su registro cuando el sistema destruye la actividad. Por lo tanto, siempre debes cancelar el registro de tu receptor de emisión.
Kotlin
class MyActivity : ComponentActivity() {
private val myBroadcastReceiver = MyBroadcastReceiver()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// ...
ContextCompat.registerReceiver(this, myBroadcastReceiver, filter, receiverFlags)
setContent { MyApp() }
}
override fun onDestroy() {
super.onDestroy()
// When you forget to unregister your receiver here, you're causing a leak!
this.unregisterReceiver(myBroadcastReceiver)
}
}
Java
class MyActivity extends ComponentActivity {
MyBroadcastReceiver myBroadcastReceiver;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// ...
ContextCompat.registerReceiver(this, myBroadcastReceiver, filter, receiverFlags);
// Set content
}
}
Registra receptores en el menor permiso posible
Tu receptor de emisión solo debe registrarse cuando realmente te interese el resultado. Elige el alcance del receptor más pequeño posible:
- Métodos de ciclo de vida
LifecycleResumeEffect
oonResume
/onPause
de la actividad: El receptor de emisión solo recibe actualizaciones mientras la app está en su estado de reanudación. - Métodos de ciclo de vida
LifecycleStartEffect
oonStart
/onStop
de la actividad: El receptor de emisión solo recibe actualizaciones mientras la app está en su estado de reanudación. DisposableEffect
: El receptor de emisión solo recibe actualizaciones mientras el elemento componible está en el árbol de composición. Este alcance no está adjunto al alcance del ciclo de vida de la actividad. Considera registrar el receptor en el contexto de la aplicación. Esto se debe a que, en teoría, el elemento componible podría sobrevivir al alcance del ciclo de vida de la actividad y filtrar la actividad.- Actividad
onCreate
/onDestroy
: El receptor de emisión recibe actualizaciones mientras la actividad está en su estado creado. Asegúrate de anular el registro enonDestroy()
y no enonSaveInstanceState(Bundle)
, ya que es posible que no se llame a este. - Un alcance personalizado: Por ejemplo, puedes registrar un receptor en tu alcance
ViewModel
para que sobreviva a la recreación de actividades. Asegúrate de usar el contexto de la aplicación para registrar el receptor, ya que este puede sobrevivir al alcance del ciclo de vida de la actividad y filtrar la actividad.
Crea elementos componibles con estado y sin estado
Compose tiene elementos componibles con estado y sin estado. Registrar o anular el registro de un receptor de emisión dentro de un elemento componible lo hace con estado. El elemento componible no es una función determinista que renderiza el mismo contenido cuando se pasan los mismos parámetros. El estado interno puede cambiar según las llamadas al receptor de transmisión registrado.
Como práctica recomendada en Compose, te recomendamos que dividas tus elementos componibles en versiones con estado y sin estado. Por lo tanto, te recomendamos que eleves la creación del receptor de emisión de un elemento componible para que no tenga estado:
@Composable
fun MyStatefulScreen() {
val myBroadcastReceiver = remember { MyBroadcastReceiver() }
val context = LocalContext.current
LifecycleStartEffect(true) {
// ...
ContextCompat.registerReceiver(context, myBroadcastReceiver, filter, flags)
onStopOrDispose { context.unregisterReceiver(myBroadcastReceiver) }
}
MyStatelessScreen()
}
@Composable
fun MyStatelessScreen() {
// Implement your screen
}
Receptores declarados en el manifiesto
Si declaras un receptor de emisión en tu manifiesto, el sistema inicia la app cuando se envía la emisión. Si la app aún no se está ejecutando, el sistema la inicia.
Para declarar un receptor de emisión en el manifiesto, realiza los siguientes pasos:
Especifica el elemento
<receiver>
en el manifiesto de tu app.<!-- If this receiver listens for broadcasts sent from the system or from other apps, even other apps that you own, set android:exported to "true". --> <receiver android:name=".MyBroadcastReceiver" android:exported="false"> <intent-filter> <action android:name="com.example.snippets.ACTION_UPDATE_DATA" /> </intent-filter> </receiver>
Los filtros de intents especifican las acciones de emisión a las que se suscribe tu receptor.
Crea la subclase
BroadcastReceiver
y, luego, implementaonReceive(Context, Intent)
. El receptor de emisión del siguiente ejemplo registra y muestra el contenido de la emisión:Kotlin
class MyBroadcastReceiver : BroadcastReceiver() { @Inject lateinit var dataRepository: DataRepository override fun onReceive(context: Context, intent: Intent) { if (intent.action == "com.example.snippets.ACTION_UPDATE_DATA") { val data = intent.getStringExtra("com.example.snippets.DATA") ?: "No data" // Do something with the data, for example send it to a data repository: dataRepository.updateData(data) } } }
Java
public static class MyBroadcastReceiver extends BroadcastReceiver { @Inject DataRepository dataRepository; @Override public void onReceive(Context context, Intent intent) { if (Objects.equals(intent.getAction(), "com.example.snippets.ACTION_UPDATE_DATA")) { String data = intent.getStringExtra("com.example.snippets.DATA"); // Do something with the data, for example send it to a data repository: if (data != null) { dataRepository.updateData(data); } } } }
El administrador de paquetes del sistema registra el receptor cuando se instala la app. Luego, el receptor se convierte en un punto de entrada a tu app independiente, lo que significa que el sistema puede iniciar la app y entregar la emisión si esta no está en ejecución.
El sistema crea un nuevo objeto componente BroadcastReceiver
para controlar cada emisión que recibe. Este objeto es válido solo durante la llamada a onReceive(Context, Intent)
. Una vez que este método muestra tu código, el sistema considera que el componente ya no está activo.
Efectos en el estado del proceso
El hecho de que tu BroadcastReceiver
esté en funcionamiento o no afecta el proceso que lo contiene, lo que puede alterar la probabilidad de que el sistema lo elimine. Un proceso en primer plano ejecuta el método onReceive()
de un receptor. El sistema ejecuta el proceso, excepto en casos de extrema presión de la memoria.
El sistema desactiva el BroadcastReceiver
después de onReceive()
.
La importancia del proceso de host del receptor depende de los componentes de la app. Si ese proceso aloja solo un receptor declarado en el manifiesto, el sistema podría finalizarlo después de onReceive()
para liberar recursos para otros procesos más críticos. Esto es común en las apps con las que el usuario nunca interactuó o no lo hizo recientemente.
Por lo tanto, los receptores de emisión no deben iniciar subprocesos en segundo plano de larga duración.
El sistema puede detener el proceso en cualquier momento después de onReceive()
para recuperar la memoria y finalizar el subproceso creado. Para mantener el proceso activo, programa un JobService
desde el receptor con JobScheduler
para que el sistema sepa que el proceso aún está en funcionamiento. En Descripción general del trabajo en segundo plano, se proporcionan más detalles.
Cómo enviar transmisiones
Android ofrece dos maneras para que las apps envíen transmisiones:
- El método
sendOrderedBroadcast(Intent, String)
envía emisiones a un receptor por vez. A medida que se ejecuta cada receptor, se puede propagar un resultado al siguiente. También puede anular por completo la transmisión para que no llegue a otros receptores. Puedes controlar el orden en que se ejecutan los receptores. Para ello, usa el atributo android:priority del filtro de intents coincidente. Los receptores con la misma prioridad se ejecutan en orden arbitrario. - El método
sendBroadcast(Intent)
envía emisiones a todos los receptores en un orden no especificado. Esto se denomina emisión normal. Este método es más eficiente, pero implica que los receptores no pueden leer los resultados de otros receptores, propagar los datos recibidos de la emisión ni anular la emisión.
En el siguiente fragmento de código, se muestra cómo enviar una emisión mediante la creación de un intent y una llamada a sendBroadcast(Intent)
.
Kotlin
val intent = Intent("com.example.snippets.ACTION_UPDATE_DATA").apply {
putExtra("com.example.snippets.DATA", newData)
setPackage("com.example.snippets")
}
context.sendBroadcast(intent)
Java
Intent intent = new Intent("com.example.snippets.ACTION_UPDATE_DATA");
intent.putExtra("com.example.snippets.DATA", newData);
intent.setPackage("com.example.snippets");
context.sendBroadcast(intent);
El mensaje de emisión está envuelto en un objeto Intent
. La cadena action
del intent debe proporcionar la sintaxis del nombre del paquete Java de la app y, además, identificar de forma exclusiva el evento de emisión. Puedes adjuntar información adicional al intent con putExtra(String, Bundle)
. También puedes limitar una transmisión a un conjunto de apps en la misma organización llamando a setPackage(String)
en el intent.
Cómo restringir emisiones con permisos
Los permisos te permiten restringir emisiones a un conjunto de apps que cuenta con permisos específicos. Puedes aplicar restricciones tanto en el emisor como en el receptor de una emisión.
Cómo enviar transmisiones con permisos
Cuando llames a sendBroadcast(Intent, String)
o sendOrderedBroadcast(Intent, String, BroadcastReceiver, Handler, int, String,
Bundle)
, puedes especificar un parámetro de permiso. Solo pueden recibir la emisión los receptores que solicitaron ese permiso con la etiqueta <uses-permission>
en su manifiesto. Si el permiso es peligroso, debes otorgarlo antes de que el receptor pueda recibir la transmisión. Por ejemplo, el siguiente código envía una transmisión con un permiso:
Kotlin
context.sendBroadcast(intent, android.Manifest.permission.ACCESS_COARSE_LOCATION)
Java
context.sendBroadcast(intent, android.Manifest.permission.ACCESS_COARSE_LOCATION);
Para recibir la emisión, la app receptora debe solicitar el permiso como se indica a continuación:
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
Puedes especificar un permiso existente del sistema como BLUETOOTH_CONNECT
o definir un permiso personalizado con el elemento <permission>
. Para obtener información sobre los permisos y la seguridad en general, consulta los Permisos del sistema.
Cómo recibir transmisiones con permisos
Si especificas un parámetro de permiso cuando registras un receptor de emisión (con registerReceiver(BroadcastReceiver, IntentFilter, String, Handler)
o en la etiqueta <receiver>
de tu manifiesto), solo los transmisores que hayan solicitado el permiso con la etiqueta <uses-permission>
en su manifiesto pueden enviar un intent al receptor. Si el permiso es peligroso, también se debe otorgar a la emisora.
Por ejemplo, supongamos que tu app receptora tiene un receptor declarado en el manifiesto como se muestra a continuación:
<!-- If this receiver listens for broadcasts sent from the system or from
other apps, even other apps that you own, set android:exported to "true". -->
<receiver
android:name=".MyBroadcastReceiverWithPermission"
android:permission="android.permission.ACCESS_COARSE_LOCATION"
android:exported="true">
<intent-filter>
<action android:name="com.example.snippets.ACTION_UPDATE_DATA" />
</intent-filter>
</receiver>
O bien la app receptora tiene un receptor registrado en el contexto, de la siguiente manera:
Kotlin
ContextCompat.registerReceiver(
context, myBroadcastReceiver, filter,
android.Manifest.permission.ACCESS_COARSE_LOCATION,
null, // scheduler that defines thread, null means run on main thread
receiverFlags
)
Java
ContextCompat.registerReceiver(
context, myBroadcastReceiver, filter,
android.Manifest.permission.ACCESS_COARSE_LOCATION,
null, // scheduler that defines thread, null means run on main thread
receiverFlags
);
Luego, para poder enviar emisiones a esos receptores, la app que las envía debe solicitar el permiso de la siguiente manera:
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
Consideraciones de seguridad
Estas son algunas consideraciones de seguridad para enviar y recibir transmisiones:
Si se registraron muchas apps para recibir la misma emisión en su manifiesto, es posible que el sistema inicie muchas apps, lo que afecta considerablemente el rendimiento del dispositivo y la experiencia del usuario. Para evitar esto, usa el registro de contexto en lugar de la declaración en el manifiesto. A veces, el propio sistema Android impone el uso de receptores registrados en el contexto. Por ejemplo, la transmisión de
CONNECTIVITY_ACTION
se entrega solo a los receptores registrados en el contexto.No emitas información sensible mediante un intent implícito. Cualquier app puede leer la información si se registra para recibir la transmisión. Existen tres maneras de controlar quién puede recibir tus emisiones:
- Puedes especificar un permiso cuando envías una emisión.
- En Android 4.0 (nivel de API 14) y versiones posteriores, puedes especificar un paquete con
setPackage(String)
cuando envías una emisión. El sistema restringe la transmisión al conjunto de apps que coinciden con el paquete.
Cuando registras un receptor, cualquier app puede enviar emisiones potencialmente maliciosas al receptor de tu app. Existen varias formas de limitar las transmisiones que recibe tu app:
- Puedes especificar un permiso cuando registras un receptor de emisión.
- En el caso de los receptores declarados en el manifiesto, puedes establecer el atributo android:exported en "false" en el manifiesto. El receptor no recibe emisiones de fuentes externas a la app.
El espacio de nombres para las acciones de emisión es global. Asegúrate de que los nombres de las acciones y otras cadenas estén escritos en un espacio de nombres del cual seas propietario. De lo contrario, es posible que entres en conflicto de forma involuntaria con otras apps.
Como el método
onReceive(Context, Intent)
de un receptor se ejecuta en el subproceso principal, debería ejecutarse y mostrarse rápidamente. Si necesitas realizar una tarea prolongada, sé cuidadoso al generar subprocesos o al iniciar servicios en segundo plano, ya que el sistema podría eliminar todo el proceso después de que se muestreonReceive()
. Para obtener más información, consulta Efectos en el estado del proceso. Para realizar una tarea prolongada, te recomendamos que hagas lo siguiente:- Llamar a
goAsync()
en el métodoonReceive()
de tu receptor y pasarBroadcastReceiver.PendingResult
a un subproceso en segundo plano De esta manera, la transmisión se mantiene activa después de que se muestra desdeonReceive()
. Sin embargo, incluso con este enfoque, el sistema espera que termines la emisión rápidamente (menos de 10 segundos). De igual manera, te permite mover la tarea a otro subproceso para evitar que se produzca un error en el subproceso principal. - Programa una tarea con
JobScheduler
. Para obtener más información, consulta Programación inteligente de tareas.
- Llamar a
No inicies actividades desde receptores de emisión porque la experiencia del usuario no es coherente, en especial, si hay varios receptores. En su lugar, considera mostrar una notificación.