Включение поддержки SMS в Hangouts 2.0 отключает BroadcastReceiver SMS_RECEIVED в моем приложении
Я только что получил обновление для 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, что является наивысшим возможным приоритетом из документации по фильтру намерений, но безуспешно. я знаю это SMS_RECEIVED
намерения отправляются по заказу, и приложения с высоким приоритетом могут прервать трансляцию. 1 Но вряд ли Hangouts 2.0 регистрирует SMS_RECEIVED
приемник с высоким приоритетом и вызов abortBroadcast()
, следовательно, не позволяя другим приложениям получать намерения.
Что еще больше смутило меня, так это то, что мой Pebble все еще может получать SMS, даже с Hangouts 2.0 в качестве стандартного SMS-приложения. Интересно, чем Pebble отличается? Я только что заметил, что входящие SMS-уведомления на моем Pebble больше не являются уведомлениями о новых SMS-сообщениях, полученных приложением Pebble, а вместо этого являются уведомлениями о "новом видеовстрече", вызванными видеовстречами, получающими входящие SMS-сообщения. Таким образом, приложение Pebble также не может получать входящие текстовые сообщения с SMS_RECEIVED
,
В дополнение к этому, я не совсем связан с этой проблемой, потому что я все еще на Android 4.3 (но мое приложение ориентировано на уровень SDK 19, на Android 4.4, если это имеет значение) В блоге Google для разработчиков Android о новом SMS API в Kitkat говорится, что ничего не изменится для приложений, использующих только SMS_RECEIVED, и не пытайтесь записать SMS-сообщение поставщику SMS.
1 Я всегда считал, что трансляция SMS_RECEIVED прерывается. Но сайт API Android 4.4 говорит что-то другое: "… когда приходит новое SMS с прослушиванием трансляции SMS_RECEIVED_ACTION, которая не подлежит прерыванию …"
5 ответов
Починил это.
Первая проблема заключалась в том, что, как вы можете видеть в пересмотре 2 моего вопроса, я поставил priority
атрибут в action
элемент, когда он на самом деле принадлежит intent-filter
элемент. Таким образом, приоритет не работал.
Несмотря на то, что я все еще нацелился на API 19, я немного поработал с Hangouts SMS и разными приоритетами.
- Приоритет не установлен → BroadcastReceiver не получает
SMS_RECEIVED
намерение - Приоритет 500 → BroadcastReceiver получает
SMS_RECEIVED
намерение - Приоритет 999 1 → BroadcastReceiver получает
SMS_RECEIVED
намерение
Таким образом, кажется, что вам нужно иметь минимальное значение приоритета, чтобы получить намерение с включенным Hangouts SMS. Я не удосужился разделить минимально возможное значение.;) Я иду с 999, так как не вижу причин снижаться, потому что мое приложение выполняет только некоторые быстрые проверки полученных смс и не обрабатывает их дальше. Но это действительно должно иметь значение, поскольку трансляция не прерывается.
Согласно последнему Манифесту 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, и это продолжает работать. Однако я установил приоритет фильтра намерений 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.MAX_VALUE. Теперь abortBroadcast() будет работать;
receiver = new HightPrioritySmsReceiver();
IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
filter.setPriority(Integer.MAX_VALUE);
registerReceiver(receiver, filter);