android - texto - hangouts en español

Habilitar el soporte de SMS en Hangouts 2.0 rompe el BroadcastReceiver de SMS_RECEIVED en mi aplicación

Question

Acabo de recibir la actualización para Hangouts 2.0, la instalé y habilité SMS → Turn on SMS . Ahora mi aplicación, que funciona con Android 4.3, ya no puede recibir SMS, es decir, mi BroadcastReceiver para SMS_RECEIVED ya no se llama. :-(

Tan pronto como deshabilito Turn on SMS en Hangouts 2.0, mi aplicación puede recibir intenciones SMS_RECEIVED nuevamente.

El receptor de Broadcast está registrado en el Manifiesto así.

AndroidManifest.xml

…
<receiver android:name=".SMSReceiver" >
<intent-filter>
<action android:name="android.provider.Telephony.SMS_RECEIVED" />
</intent-filter>
</receiver>
…

SMSReceiver.java

public class SMSReceiver extends BroadcastReceiver {
private static final Log LOG = Log.getLog();
@Override
public void onReceive(Context context, Intent intent) {
LOG.d("onReceive");
…
}
}

Ya intenté cambiar la prioridad del receptor a INT_MAX o 999, que es la prioridad más alta posible en la documentación del filtro de intento , pero sin éxito. Sé que los intentos de SMS_RECEIVED se envían ordenados y que las aplicaciones de alta prioridad tienen la capacidad de abortar la transmisión. ¹ Pero parece poco probable que Hangouts 2.0 esté registrando el receptor SMS_RECEIVED con una prioridad alta y llamando a abortBroadcast() , lo que impide que otras aplicaciones reciban la intención.

Lo que más me confundió es que mi Pebble aún puede recibir SMS, incluso con Hangouts 2.0 como aplicación de SMS predeterminada. Me pregunto que hace Pebble diferente. Acabo de darme cuenta de que la notificación de SMS entrante en mi Pebble ya no son notificaciones de nuevos SMS recibidos por la aplicación Pebble, sino que son notificaciones de "nuevo mensaje de Hangout" causadas por hangouts que reciben el SMS entrante. Por lo tanto, la aplicación Pebble tampoco puede recibir mensajes de texto entrantes con SMS_RECEIVED .

En una nota al margen y no realmente relacionada con este problema, porque todavía estoy en Android 4.3 (pero mi aplicación apunta al SDK de nivel 19, Android 4.4 en caso de que sea importante) La publicación del blog de desarrolladores de Android de Google sobre la nueva API de SMS en Kitkat , dijo que nada cambiaría para las aplicaciones que utilizan solo SMS_RECEIVED y no intente escribir el SMS en el proveedor de SMS.

¹ Siempre creí que la transmisión SMS_RECEIVED es abortable. Pero el sitio de Android 4.4 API dice algo diferente: "... cuando llega un nuevo SMS escuchando la transmisión de SMS_RECEIVED_ACTION, que es una transmisión no abortable ..."

Answer 1

Cuando registre el receptor, establezca la prioridad del filtro en INTEGER.MAX_VALUE. Ahora abortBroadcast () funcionará;

receiver = new HightPrioritySmsReceiver();
IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
filter.setPriority(Integer.MAX_VALUE);
registerReceiver(receiver, filter);

Answer 2

De acuerdo con el Manifiesto de Google Hangouts más reciente, tienen un conjunto AbortSmsReceiver con una prioridad de "3", por lo que parece que cualquier aplicación que quiera recibir la transmisión SMS_RECEIVED en API 18 o inferior debe usar una prioridad superior a 3:

<receiver android:name="com.google.android.apps.babel.sms.AbortSmsReceiver" android:permission="android.permission.BROADCAST_SMS" android:enabled="false">
<intent-filter android:priority="3">
<action android:name="android.provider.Telephony.SMS_RECEIVED" />
</intent-filter>
</receiver>

Puede usar un destino de compilación de API 19. Las aplicaciones en un dispositivo que ejecuta API 19 (KitKat) no podrán abortar la transmisión como en las API anteriores. Esto evita que las aplicaciones realicen un aborto prematuro.

Supongo que incluyeron este aborto para evitar que las aplicaciones de mensajería de stock publiquen notificaciones duplicadas. Las aplicaciones de mensajería de archivo deben procesarse con la prioridad 0 antes de KitKat, pero cualquier aplicación que no establezca una prioridad también se procesa en 0. Los objetos IntentFilter se crean con un valor de prioridad predeterminado de "0":

public IntentFilter() {
mPriority = 0;
mActions = new ArrayList<String>();
}

Answer 3

Estoy teniendo el mismo problema. Estoy apuntando a SDK 17, y aún no puedo obtener la transmisión si Hangouts está habilitado para manejar SMS. Quién sabe cuántas aplicaciones Hangouts acaba de llegar al mercado.

Intentaré ajustar la prioridad y ver si eso ayuda.

[edit] Sí, la prioridad me la arreglé en el sdk 17. ¡Gracias!

Answer 4

Todavía puedo conseguir bien la emisión. Acaba de instalar los nuevos hangouts y habilitado SMS. En mi caso, solo estoy leyendo los contenidos de SMS y eso sigue funcionando. Lo que he hecho, sin embargo, fue establecer la prioridad del filtro de intento en 999 siguiendo un hilo anterior aquí :

<intent-filter android:priority="999" >
<action android:name="android.provider.Telephony.SMS_RECEIVED" />
</intent-filter>

Tal vez eso está jugando un papel?

ACTUALIZACIÓN: Simplemente lea que cambió su destino al nivel 19 del SDK. En ese caso, leí que tiene que cambiar el comportamiento de su aplicación (no puede encontrar el enlace ahora) siguiendo las pautas de API 19. Cambia tu objetivo de nuevo a 18 y debería funcionar bien.

Answer 5

Arreglado.

El primer problema fue que, como puede ver en la revisión 2 de mi pregunta , puse el atributo de priority dentro del elemento de action , cuando en realidad pertenece al elemento de intent-filter . Así que la prioridad no funcionó.

Mientras seguía apuntando a API 19, realicé algunas experiencias con Hangouts habilitados para SMS y diferentes prioridades.

• Sin prioridad establecida → BroadcastReceiver no recibe el intento SMS_RECEIVED
• Prioridad 500 → BroadcastReceiver recibe el intento SMS_RECEIVED
• Prioridad 999 ¹ → BroadcastReceiver recibe el intento SMS_RECEIVED

Por lo tanto, parece que necesitas tener un valor mínimo de prioridad para obtener la intención con Hangouts SMS habilitado. No me molesté en bisecar el valor más bajo posible. ;) Me voy con 999 porque no veo ninguna razón para bajar porque mi aplicación hace solo algunas comprobaciones rápidas de los sms recibidos y no los procesa más. Pero realmente debería hacer una diferencia, ya que la transmisión no es abortable.

¹ El valor máximo