Se usó la API de Cloud Translation para traducir esta página.

Descripción general de las transmisiones

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.13.1"

    // 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.13.1"

    // 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 marca RECEIVER_NOT_EXPORTED.

Algunas transmisiones del sistema provienen de apps con privilegios elevados, como Bluetooth y telefonía, que forman parte del framework de Android, pero no se ejecutan con el ID de proceso único (UID) del sistema. Para recibir todas las transmisiones del sistema, incluidas las de apps con privilegios elevados, marca tu receptor con RECEIVER_EXPORTED.

Si marcas tu receptor con RECEIVER_NOT_EXPORTED, este puede recibir algunas transmisiones del sistema y de tu app, pero no las transmisiones de las apps con privilegios elevados.

Si tu app está escuchando varias transmisiones, pero solo algunas deben marcarse como RECEIVER_NOT_EXPORTED y otras como RECEIVER_EXPORTED, particiona las transmisiones entre diferentes receptores de transmisión.
Kotlin
```
val listenToBroadcastsFromOtherApps = false
val receiverFlags = if (listenToBroadcastsFromOtherApps) {
    ContextCompat.RECEIVER_EXPORTED
} else {
    ContextCompat.RECEIVER_NOT_EXPORTED
}BroadcastReceiverSnippets.kt
```
Java
```
boolean listenToBroadcastsFromOtherApps = false;
int receiverFlags = listenToBroadcastsFromOtherApps
        ? ContextCompat.RECEIVER_EXPORTED
        : ContextCompat.RECEIVER_NOT_EXPORTED;BroadcastReceiverJavaSnippets.java
```
Precaución: Si exportas el receptor de emisión, otras apps podrían enviar transmisiones sin protección a tu app.

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)
    }
}BroadcastReceiverSnippets.kt

Java

class MyActivity extends ComponentActivity {
    MyBroadcastReceiver myBroadcastReceiver;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // ...
        ContextCompat.registerReceiver(this, myBroadcastReceiver, filter, receiverFlags);
        // Set content
    }
}BroadcastReceiverJavaSnippets.java

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 o onResume/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 o onStart/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 en onDestroy() y no en onSaveInstanceState(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
}BroadcastReceiverSnippets.kt

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>AndroidManifest.xml

Los filtros de intents especifican las acciones de emisión a las que se suscribe tu receptor.

Crea la subclase BroadcastReceiver y, luego, implementa onReceive(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)
        }
    }
}BroadcastReceiverSnippets.kt

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); }
        }
    }
}BroadcastReceiverJavaSnippets.java

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)BroadcastReceiverSnippets.kt

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);BroadcastReceiverJavaSnippets.java

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>AndroidManifest.xml

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
)BroadcastReceiverSnippets.kt

Java

ContextCompat.registerReceiver(
        context, myBroadcastReceiver, filter,
        android.Manifest.permission.ACCESS_COARSE_LOCATION,
        null, // scheduler that defines thread, null means run on main thread
        receiverFlags
);BroadcastReceiverJavaSnippets.java

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 muestre onReceive(). 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étodo onReceive() de tu receptor y pasar BroadcastReceiver.PendingResult a un subproceso en segundo plano De esta manera, la transmisión se mantiene activa después de que se muestra desde onReceive(). 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.
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.