Эти забавные BroadcastReceiver'ы

Небольшое наблюдение о различном поведении BroadcastReceiver'ов при регистрации через AndroidManifest.xml и непосредственно в коде. Данная заметка не является пошаговым руководством для новичков, а всего лишь призвана сэкономить время тем, кому еще не довелось наступить на похожие грабли.

Так уж вышло, волею project manager судьбы, довелось мне писать программу, блокирующую все и вся во благо беззащитных деток. Оставим в стороне этическую составляющую вопроса и психическую адекватность родителей, которые выкидывают сотни три-четыре евро на смартфон для дитяти, а потом с завидным упорством ищут софт, который превратит это высокотехнологичное устройство в кирпич десятилетней давности: без интернета, без смс, без звонков, без приложений… без надежды на будущее. Попытка заменить воспитание тотальным контролем – верный способ вырастить безвольного имбецила, но чукча здесь не решатель, чукча кодо-писатель, так что предлагаю сосредоточиться на технической стороне дела.

Конкретная подзадача такого рода программ: получать уведомления о смене состояний мобильного интернета, Wi-Fi, Bluetooth и блокировать их в зависимости от степени параноидальности опекающего. Как известно, такого рода оповещения в андроиде реализованны через BroadcastReceiver'ы. Также, не секрет, что зарегистрировать receiver можно двумя способами: в файле AndroidManifest.xml и непосредственно в Activity(или Service, как вариант). Рассмотрим оба способа.

AndroidManifest.xml

/* тут демонстрируется знание народного фольклора и производится сравнение с паренной репой*/. Не мудрствуя лукаво, подпишемся на нужные нам события. В данном случае, это action'ы так или иначе содержащие в себе change.

<receiver
    android:name="com.demo.WiFiReceiver"
    android:enabled="true" >
    <intent-filter>
        <action android:name="android.net.wifi.WIFI_STATE_CHANGED" />
    </intent-filter>
</receiver>

<receiver
    android:name="com.demo.DataReceiver"
    android:enabled="true" >
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

<receiver android:name="com.demo.BluetoothReceiver" 
    android:enabled="true">
    <intent-filter>
        <action android:name="android.bluetooth.adapter.action.STATE_CHANGED" />
    </intent-filter>
</receiver>

Соответствующие им классы выглядят не намного сложнее и в общем виде соответствуют следующему шаблону:

public class MyReceiver extends BroadcastReceiver {

  @Override
  public void onReceive(Context context, Intent intent) {
    Log.d("MyReceiver", "onReceive");
  }
}

Нас интересует хронология вызовов, поэтому будем вести лог наступления основных событий.
Результат на лицо в LogCat:

Application	Tag	Text
com.habr	MyActivity	onCreate

и при каждом вкл/выкл соответсвующей опции получим к примеру:

Application	Tag	Text
com.habr	WiFiReceiver	onReceive

Все довольно предсказуемо.

Программно.

Сначала проделаем этот нехитрый трюк на примере Bluetooth.

@Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    Log.d("MyActivity", "onCreate");    
  }

@Override
  protected void onResume() {
    super.onResume();
    receiver = new BroadcastReceiver() {      
      @Override
      public void onReceive(Context context, Intent intent) {
        Log.e("BluetoothReceiver", "onReceive");        
      }
    };
    registerReceiver(receiver, new IntentFilter(BluetoothAdapter.ACTION_SCAN_MODE_CHANGED));
  }
  
  @Override
  protected void onPause() {
    super.onPause();
    unregisterReceiver(receiver);
  }

Поведение будет идентично предыдущим запускам и у многих в голове уже наверняка не первый раз пронеслась мысль «зачем, таки, он делает нам доктора и кого он здесь вообще лечит?», но попробуйте запустить тот же код, изменив action на WifiManager.WIFI_STATE_CHANGED_ACTION или ConnectivityManager.CONNECTIVITY_ACTION и тут, привет ребятам из андроид, вы обнаружите, что LogCat показывает следующее:

Application	Tag	Text
com.habr	MyActivity	onCreate
com.habr	WiFiReceiver	onReceive
com.habr	DataReceiver	onReceive

Фактически, это означает, что onReceive обоих receiver'ов вызвался сразу, вообще вне зависимости от состояния соответствующих опций и только Bluetooth повел себя корректно.

Вывод

Представьте себе простую ситуацию: задача приложения оборвать интернет. В момент установки приложения, он может быть как включенным так и выключенным. Если он уже включен, и вы регистрируетесь через AndroidManifest.xml, то вам, just to be sure, придется вызвать код блокировки из receiver'a самостоятельно, т.к. системой вы оповещены не будете и это правильно, потому что вы опоздали на обед, соответствующее оповещение пробросилось, когда вас с вашим приложением в системе еще не было. Если же вы все сделали программно, то делать отдельный вызов не придется. Опять же, при условии, что дело не касается Bluetooth. Если задаться вопросом «А, собсна, какого почему?», то ответ скорее всего будет «Потому что могем!». Как по мне, так это чистой воды баг и логики никакой не просматривается. Надеюсь эта статья сэкономит кому-то тот день, который я убил, чтобы понять в чем причина непослушания адской машины.

Все вышеописанное воспроизводится на всех версиях Android, начиная с Gingerbread и выше(ниже просто не тестировал).

Что касается непосредственно методов фильтрации звонков, смс, интернета и т.д., то, если не ошибаюсь, тема уже частично освещалась, например здесь. Но, если это интересно, то я мог бы попробовать внести свою лепту так, чтобы никого не дублировать.