android - studio - Broadcast Receiver Register in Manifest vs. Activity

webview android studio 2017

Question

Necesito ayuda para entender cuándo puedo esperar que mi receptor de difusión funcione cuando acaba de registrarse en el manifiesto en lugar de tener que estar registrado desde una actividad o servicio en ejecución.

Entonces, por ejemplo, si registro un receptor independiente con el siguiente filtro de intención, funciona sin tener una referencia de servicio / actividad:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.blk_burn.standalonereceiver"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk android:minSdkVersion="10" />
<uses-permission android:name="android.permission.WAKE_LOCK"/>
<application
android:icon="@drawable/ic_launcher"
android:label="@string/app_name" >
<receiver android:name="TestReceiver">
<intent-filter>
<action android:name="android.media.AUDIO_BECOMING_NOISY"/>
</intent-filter>
</receiver>
</application>
</manifest>

Sin embargo, si reemplazo android.media.AUDIO_BECOMING_NOISY con android.intent.action.HEADSET_PLUG el receptor no se desencadena ( Documentación de Android )

Según lo que encontré en este sitio, debe registrar este receptor de una actividad o servicio que ya se está ejecutando para que funcione ( Post ).

• ¿Alguien puede decirme por qué esto no funciona cuando solo ajusta su filtro de intención en el manifiesto y por qué necesita tener un servicio ejecutándose en segundo plano que haga referencia / registre el receptor?

• ¿Hay algún problema para poder registrar mi receptor en el manifiesto de mi aplicación utilizando un filtro de intención con android.intent.action.HEADSET_PLUG ?

• ¿Cómo puedo identificar qué acciones de difusión de la documentación de Android necesitan tener un servicio o actividad registrarlas frente a solo tener el filtro correcto en el manifiesto?

Answer 1

Como es habitual, los receptores de difusión se pueden configurar en el archivo de manifiestoAndroidManifest.xml. Un BroadcastReceiver que está configurado de esta manera se llama estáticamente registrado.

Puede registrar su receptor en el archivo de manifiesto utilizando el elemento:

<receiver
android:name=".ConnectivityChangeReceiver">
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
</receiver>

El elemento anidado se usa para especificar el evento al que el receptor debería reaccionar.

Receptores de transmisión dinámicos

Como alternativa, puede registrar su implementación de BroadcastReceiver dinámicamente en su código. Solo necesita llamar al método registerReceiver () en su objeto Context.

El método registerReceiver () toma dos parámetros:

Los argumentos del método registerReceiver ()

• receptor: el BroadcastReceiver que desea registrar
• filter: El objeto IntentFilter que especifica qué evento debe escuchar su receptor.

Cuando registra su receptor de esta manera, vive mientras viva el componente, y Android envía eventos a este receptor hasta que se destruye el componente de creación.

Es su tarea manejar el ciclo de vida correctamente. Por lo tanto, cuando agrega un receptor dinámicamente, ¡tenga cuidado de anular el registro del mismo receptor en el método onPause () de su Actividad!

Sugiero registrar el receptor en el método onResume () de tu Actividad y anular el registro en tu método onPause ():

@Override
protected void onPause() {
unregisterReceiver(mReceiver);
super.onPause();
}
@Override
protected void onResume() {
this.mReceiver = new ConnectivityChangeReceiver();
registerReceiver(
this.mReceiver,
new IntentFilter(
ConnectivityManager.CONNECTIVITY_ACTION));
super.onResume();
}

Cuándo usar qué método registrar

El método que se utilizará para registrar su BroadcastReceiver depende de lo que haga su aplicación con el evento del sistema. Creo que hay básicamente dos razones por las que su aplicación quiere saber sobre eventos en todo el sistema:

• Tu aplicación ofrece algún tipo de servicio en torno a estos eventos
• Tu aplicación quiere reaccionar amablemente a los cambios de estado

Los ejemplos de la primera categoría son aplicaciones que deben funcionar apenas se inicia el dispositivo o que deben comenzar algún tipo de trabajo cada vez que se instala una aplicación. Battery Widget Pro o App2SD son buenos ejemplos para este tipo de aplicaciones. Para este tipo, debe registrar BroadcastReceiver en el archivo Manifest.

Los ejemplos para la segunda categoría son eventos que indican un cambio en las circunstancias en las que su aplicación podría contar. Supongamos que su aplicación depende de una conexión Bluetooth establecida. Debe reaccionar ante un cambio de estado, pero solo cuando su aplicación esté activa. En este caso, no hay necesidad de un receptor de difusión estáticamente registrado. Una registrada dinámicamente sería más razonable.

También hay algunos eventos para los que ni siquiera se te permite registrarte estáticamente. Un ejemplo de esto es el evento Intent.ACTION_TIME_TICK que se transmite cada minuto. Lo cual es una decisión acertada porque un receptor estático podría drenar innecesariamente la batería.

Answer 2

Si su receptor está registrado en el manifiesto y su aplicación no se está ejecutando, se creará un nuevo proceso para manejar la transmisión. Si lo registra en código, está ligado a la vida de la actividad / servicio en el que lo registró. Para algunas transmisiones, realmente no tiene sentido crear un nuevo proceso de aplicación si no existe, o hay algunas implicaciones de seguridad, rendimiento, etc., y por lo tanto, solo puede registrar el receptor en el código.

En cuanto a la transmisión HEADSET_PLUG , parece que la idea es que la aplicación que ya está ejecutando pueda hacer ajustes específicos de la aplicación en la interfaz de usuario, el volumen, etc. Si su aplicación no se está ejecutando, no debería preocuparse por desconectar los auriculares. .

AFAIK, no hay un solo lugar donde se resuma esta información para todas las transmisiones, pero cada Intento debería tener un comentario en el JavaDoc sobre cómo registrarlo y usarlo, pero aparentemente falta en algunos lugares. Debería poder compilar una lista si Intent.FLAG_RECEIVER_REGISTERED_ONLY árbol fuente de Android para Intent.FLAG_RECEIVER_REGISTERED_ONLY .