Registro de Receptor de Difusión en Manifiesto vs. Actividad

Necesito ayuda para entender cuándo puedo esperar que mi receptor de difusión funcione cuando recién se registre en el manifiesto en vez de tener que ser registrado de una actividad o servicio en ejecución.

Por ejemplo, si registro un receptor independiente con el siguiente filtro de intenciones, 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 activa ( Documentación de Android )

De lo que encontré en este sitio tienes que registrar este receptor de una actividad o servicio que ya está funcionando para que funcione ( Publicar ).

  • ¿Puede alguien decirme por qué esto no funciona cuando sólo el ajuste de su filtro de intención en el manifiesto y por qué necesita tener un servicio de ejecución en el fondo que las referencias / registros del receptor?

  • ¿Hay un trabajo alrededor de modo que puedo registrar mi receptor en el manifiesto de mi aplicación usando un filtro 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 para registrarlas en lugar de tener el filtro adecuado en el manifiesto?

2 Solutions collect form web for “Registro de Receptor de Difusión en Manifiesto vs. Actividad”

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á vinculado a la vida de la actividad / servicio en el que se registró. Para algunas transmisiones, no tiene sentido crear un nuevo proceso de aplicación si no existe, o hay algunas Seguridad, rendimiento, etc., y por lo tanto sólo puede registrar el receptor en código.

En cuanto a la emisión de HEADSET_PLUG , parece que la idea es que su aplicación ya está ejecutando puede hacer esto para hacer ajustes específicos de la aplicación a la interfaz de usuario, volumen, etc Si su aplicación no se está ejecutando, no debería preocuparse por los auriculares que se desenchufa .

AFAIK, no hay un solo lugar esta información se resume para todas las emisiones, pero cada Intención debe tener un comentario en el JavaDoc sobre cómo registrarse y usarlo, pero al parecer le falta en algunos lugares. Debe poder compilar una lista si grep el árbol de fuentes de Android para Intent.FLAG_RECEIVER_REGISTERED_ONLY .

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

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

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

El elemento anidado se utiliza para especificar el evento al que el receptor debe reaccionar.

Dyanmic Broadcast Recievers

Como alternativa, puede registrar su implementación BroadcastReceiver dinámicamente en su código. Sólo tiene que 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 el componente vive y Android envía eventos a este receptor hasta que el propio componente de creación se destruye.

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

Sugiero que registre el receptor en el método onResume () de su actividad y que lo anule en su 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 a utilizar para registrar tu BroadcastReceiver depende de lo que haga tu aplicación con el evento del sistema. Creo que hay básicamente dos razones por las que su aplicación desea saber acerca de los eventos de todo el sistema:

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

Ejemplos para la primera categoría son las aplicaciones que deben funcionar tan pronto como se arranque el dispositivo o que deben comenzar algún tipo de trabajo siempre que se instale una aplicación. Battery Widget Pro o App2SD son buenos ejemplos para este tipo de aplicaciones. Para este tipo debe registrar el BroadcastReceiver en el archivo Manifest.

Ejemplos para la segunda categoría son eventos que indican un cambio en las circunstancias en las que su aplicación podría confiar. Supongamos que su aplicación depende de una conexión Bluetooth establecida. Tienes que reaccionar ante un cambio de estado, pero sólo cuando la aplicación está activa. En este caso no hay necesidad de un receptor de emisión estáticamente registrado. Un registro dinámicamente registrado sería más razonable.

También hay algunos eventos que ni siquiera se les permite registrarse de forma estática. Un ejemplo de esto es el evento Intent.ACTION_TIME_TICK que se emite cada minuto. Cuál es una decisión sabia porque un receptor estático drenaría innecesariamente la batería.

  • Android nfc intent-filter para mostrar mi aplicación cuando nfc descubre una etiqueta
  • Redirigir la vista web de Android con el filtro de intenciones
  • IntentService no se está llamando
  • Abrir mi aplicación para un determinado archivo y extensión de URL - intento-filtro no funciona como se pretende
  • Filtro de intenciones usando path, pathPrefix o pathPattern
  • Manejo de URL específicas con filtros de intenciones en Xamarin Mono para Android
  • "La actividad exportada no requiere permiso" al intentar iniciar desde un URI
  • No se puede instanciar el receptor, java.lang.IllegalAccessException: acceso a la clase no permitido
  • El fragmento no se reanuda con su actividad después de usar el intercambio de intenciones
  • Cómo agregar un elemento de menú compartido a Galería por código
  • Firebase Deep-link abrir juego de la tienda incluso cuando la aplicación está instalada
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.