Включение поддержки SMS в Hangouts 2.0 разрывает BroadcastReceiver SMS, полученных в моем приложении
Я только что получил обновление для Hangouts 2.0, установил его и включил SMS
→ Turn on SMS
. Теперь мое приложение, работающее под Android 4.3, больше не может получать SMS, т. е. мой BroadcastReceiver для SMS_RECEIVED
больше не звонил. :-(
как только я отключу Turn on SMS
в Hangouts 2.0 мое приложение может снова получать sms_received намерения.
широковещательный приемник зарегистрирован в манифесте, как это
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");
…
}
}
я уже пытался изменить приоритет приемника на INT_MAX или 999, который является наивысший возможный приоритет в документации intent-filter, но без успеха. я знаю, что SMS_RECEIVED
намерения отправить заказаны и что высокоприоритетные приложения имеют возможность прервать трансляцию.1 Но кажется маловероятным, что Hangouts 2.0 регистрирует SMS_RECEIVED
приемник с высоким приоритетом и вызов abortBroadcast()
, поэтому предотвращение любых других приложений от получения намерения.
что еще больше смутило меня, так это то, что мой Pebble по-прежнему может получать SMS, даже с Hangouts 2.0 в качестве SMS-приложения по умолчанию. Интересно, что делает Pebble по-другому? я только что заметил, что входящее SMS-уведомление на моем Pebble больше не уведомления для новых SMS которые получены приложением Pebble, но вместо этого являются уведомлениями" new Hangout message", вызванными hangouts, получающими входящие SMS. Таким образом, приложение Pebble также не может получать входящие текстовые сообщения с SMS_RECEIVED
.
на боковой ноте и на самом деле не связан с этой проблемой, потому что я все еще на Android 4.3 (но мое приложение нацелено на SDK level 19, Android 4.4, если это имеет значение) Google Android Developers Blog post о новый SMS API в Kitkat, сказал что ничего не изменится для приложений, использующих только SMS_RECEIVED и не пытайтесь написать SMS поставщику SMS.
1 я всегда считал, что передача SMS_RECEIVED прерывается. Но ... --45-- > Android 4.4 API сайт говорит что-то другое: "... когда приходит новое SMS, прослушивая трансляцию SMS_RECEIVED_ACTION, которая является не abortable эфир..."
5 ответов
исправил.
первой проблемой было то, что, как вы можете видеть в пересмотр 2 моего вопроса, я поставил priority
атрибуты action
элемент, когда он фактически принадлежит intent-filter
элемент. Так что приоритет не сработал.
по-прежнему ориентируясь на API 19, я сделал некоторые опыты с Hangouts SMS включен и различные приоритеты.
- нет набора приоритетов → BroadcastReceiver не получает
SMS_RECEIVED
намерение!--18--> - Приоритет 500 → BroadcastReceiver тут получать
SMS_RECEIVED
намерение - приоритет 9991 → BroadcastReceiver тут получать
SMS_RECEIVED
намерение
таким образом, кажется, что вам нужно иметь минимальное значение для приоритета, чтобы получить намерение с Hangouts SMS включен. Я не стал делить пополам наименьшее возможное значение. ;) Я иду с 999, поскольку я не вижу причин опускаться, потому что мое приложение делает просто некоторые быстрые проверки на полученных sms и не обрабатывает его в дальнейшем. Но это должно действительно сделать разницу, как вещают не abortable.
согласно последнему Манифесту Google Hangouts, у них есть набор AbortSmsReceiver с приоритетом " 3 " - поэтому кажется, что любое приложение, которое хочет получить трансляцию SMS_RECEIVED на API 18 или ниже, должно использовать приоритет выше 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>
вы можете использовать цель сборки API 19. Приложения на устройстве под управлением API 19 (KitKat) не сможет прервать трансляцию, как в предыдущих API. Это предотвращает преждевременное прерывание приложений.
Я предполагаю,что они включили этот аборт, чтобы предотвратить размещение дубликатов уведомлений в приложениях обмена сообщениями. Приложения обмена сообщениями должны обрабатывать приоритет 0 до KitKat-но любое приложение, которое не устанавливает приоритет, также обрабатывается в 0. Объекты IntentFilter создаются со значением приоритета по умолчанию "0":
public IntentFilter() {
mPriority = 0;
mActions = new ArrayList<String>();
}
Я все еще могу получить трансляцию в порядке. Просто установил новые тусовки и включил SMS. В моем случае я просто читаю содержимое SMS, и это продолжает работать. Однако я сделал следующее: установил приоритет фильтра намерений на 999 после предыдущие темы здесь:
<intent-filter android:priority="999" >
<action android:name="android.provider.Telephony.SMS_RECEIVED" />
</intent-filter>
может это играет роль?
обновление: Просто прочитайте, что вы изменили свою цель на уровень SDK 19. В этом случае я читал, что вы должны изменить, как ваше приложение ведет себя (не может найти ссылку сейчас), Следуя рекомендациям API 19. Измените свою цель на 18, и она должна работать нормально.
У меня такая же проблема. Я нацелен на sdk 17, и я все еще не могу получить трансляцию, если Hangouts включен для обработки SMS. Кто знает, сколько приложений Hangouts просто сломались на рынке.
Я попробую настроить приоритет и посмотреть, поможет ли это.
[редактирование] Да, приоритет исправил его для меня на целевом sdk 17. спасибо!
при регистрации приемника установите приоритет фильтра в INTEGER.МАКСИМАЛЬНОЕ ЗНАЧЕНИЕ. Теперь abortBroadcast() будет работать;
receiver = new HightPrioritySmsReceiver();
IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
filter.setPriority(Integer.MAX_VALUE);
registerReceiver(receiver, filter);