Przegląd transmisji

Aplikacje na Androida wysyłają i odbierają komunikaty rozgłoszeniowe z systemu Android i innych aplikacji na Androida, podobnie jak w przypadku wzorca projektowego publikowania i subskrybowania. System i aplikacje zwykle wysyłają komunikaty rozgłoszeniowe, gdy wystąpią określone zdarzenia. Na przykład system Android wysyła komunikaty rozgłoszeniowe, gdy wystąpią różne zdarzenia systemowe, takie jak uruchomienie systemu lub ładowanie urządzenia. Aplikacje wysyłają też niestandardowe komunikaty rozgłoszeniowe, np. aby powiadomić inne aplikacje o czymś, co może je zainteresować (np. o pobraniu nowych danych).

Aplikacje mogą się zarejestrować, aby otrzymywać określone komunikaty rozgłoszeniowe. Gdy komunikat rozgłoszeniowy zostanie wysłany, system automatycznie kieruje go do aplikacji, które subskrybują odbieranie tego konkretnego typu komunikatu.

Ogólnie rzecz biorąc, komunikaty rozgłoszeniowe mogą być używane jako system przesyłania wiadomości między aplikacjami i poza normalnym przepływem pracy użytkownika. Musisz jednak uważać, aby nie nadużywać możliwości odpowiadania na komunikaty rozgłoszeniowe i uruchamiania zadań w tle, które mogą przyczyniać się do spowolnienia działania systemu.

Komunikaty rozgłoszeniowe systemu

System automatycznie wysyła komunikaty rozgłoszeniowe, gdy wystąpią różne zdarzenia systemowe, np. gdy system przełącza się w tryb samolotowy lub z niego wychodzi. Wszystkie subskrybowane aplikacje otrzymują te komunikaty rozgłoszeniowe.

Komunikat rozgłoszeniowy jest opakowany w obiekt Intent. Ciąg znaków action identyfikuje zdarzenie, które wystąpiło, np. android.intent.action.AIRPLANE_MODE. Intencja może też zawierać dodatkowe informacje spakowane w polu dodatkowym. Na przykład intencja trybu samolotowego zawiera dodatkową wartość logiczną, która wskazuje, czy tryb samolotowy jest włączony.

Więcej informacji o tym, jak odczytywać intencje i pobierać z nich ciąg znaków działania z intencji, znajdziesz w artykule Intencje i filtry intencji.

Działania związane z komunikatami systemowymi

Pełną listę działań związanych z komunikatami systemowymi znajdziesz w pliku BROADCAST_ACTIONS.TXT w pakiecie Android SDK. Każde działanie związane z komunikatem rozgłoszeniowym ma powiązane z nim pole stałe. Na przykład wartość stałej ACTION_AIRPLANE_MODE_CHANGED to android.intent.action.AIRPLANE_MODE. Dokumentacja każdego działania związanego z komunikatem rozgłoszeniowym jest dostępna w powiązanym z nim polu stałym.

Zmiany w komunikatach rozgłoszeniowych systemu

W miarę rozwoju platformy Android okresowo zmienia się sposób działania komunikatów rozgłoszeniowych systemu. Aby obsługiwać wszystkie wersje Androida, pamiętaj o tych zmianach.

Android 16

W Androidzie 16 kolejność dostarczania komunikatów rozgłoszeniowych za pomocą atrybutu android:priority lub IntentFilter.setPriority() w różnych procesach nie będzie gwarantowana. Priorytety komunikatów rozgłoszeniowych są uwzględniane tylko w ramach tego samego procesu aplikacji, a nie we wszystkich procesach.

Priorytety komunikatów rozgłoszeniowych są też automatycznie ograniczane do zakresu (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). Tylko komponenty systemowe mogą ustawiać SYSTEM_LOW_PRIORITY i SYSTEM_HIGH_PRIORITY jako priorytet komunikatu rozgłoszeniowego.

Android 14

Gdy aplikacje są w stanie buforowanym, system optymalizuje dostarczanie komunikatów rozgłoszeniowych pod kątem stanu systemu. Na przykład gdy aplikacja jest w stanie buforowanym, system odracza mniej ważne komunikaty rozgłoszeniowe systemu takie jak ACTION_SCREEN_ON. Gdy aplikacja przejdzie ze stanu buforowanego do aktywnego cyklu życia procesu, system dostarczy wszystkie odroczone komunikaty rozgłoszeniowe.

Ważne komunikaty rozgłoszeniowe zadeklarowane w pliku manifestu tymczasowo usuwają aplikacje ze stanu buforowanego na czas dostarczenia.

Android 9

Począwszy od Androida 9 (poziom interfejsu API 28), komunikat rozgłoszeniowy NETWORK_STATE_CHANGED_ACTION nie zawiera informacji o lokalizacji użytkownika ani danych umożliwiających identyfikację.

Jeśli Twoja aplikacja jest zainstalowana na urządzeniu z Androidem 9.0 (poziom interfejsu API 28) lub nowszym, system nie uwzględnia w komunikatach rozgłoszeniowych Wi-Fi identyfikatorów SSID, BSSID, informacji o połączeniu ani wyników skanowania. Aby uzyskać te informacje, zamiast tego wywołaj getConnectionInfo().

Android 8.0

Począwszy od Androida 8.0 (poziom interfejsu API 26), system nakłada dodatkowe ograniczenia na odbiorniki zadeklarowane w pliku manifestu.

Jeśli Twoja aplikacja jest kierowana na Androida 8.0 lub nowszego, nie możesz używać pliku manifestu do deklarowania odbiornika większości niejawnych komunikatów rozgłoszeniowych (komunikatów rozgłoszeniowych, które nie są kierowane konkretnie na Twoją aplikację). Gdy użytkownik aktywnie korzysta z Twojej aplikacji, nadal możesz używać odbiornika zarejestrowanego w kontekście.

Android 7.0

Android 7.0 (poziom interfejsu API 24) i nowsze wersje nie wysyłają tych komunikatów rozgłoszeniowych systemu:

• ACTION_NEW_PICTURE
• ACTION_NEW_VIDEO

Aplikacje kierowane na Androida 7.0 i nowsze wersje muszą też rejestrować komunikat rozgłoszeniowy CONNECTIVITY_ACTION za pomocą registerReceiver(BroadcastReceiver, IntentFilter). Deklarowanie odbiornika w pliku manifestu nie działa.

Odbieranie komunikatów rozgłoszeniowych

Aplikacje mogą odbierać komunikaty rozgłoszeniowe na 2 sposoby: za pomocą odbiorników zarejestrowanych w kontekście i odbiorników zadeklarowanych w pliku manifestu.

Odbiorniki zarejestrowane w kontekście

Odbiorniki zarejestrowane w kontekście odbierają komunikaty rozgłoszeniowe, dopóki ich kontekst rejestracji jest prawidłowy. Zwykle dzieje się to między wywołaniami registerReceiver i unregisterReceiver. Kontekst rejestracji staje się też nieprawidłowy, gdy system niszczy odpowiedni kontekst. Jeśli na przykład zarejestrujesz się w kontekście Activity, będziesz otrzymywać komunikaty rozgłoszeniowe, dopóki działanie pozostanie aktywne. Jeśli zarejestrujesz się w kontekście aplikacji, będziesz otrzymywać komunikaty rozgłoszeniowe, dopóki aplikacja będzie działać.

Aby zarejestrować odbiornik w kontekście, wykonaj te czynności:

1. W pliku kompilacji na poziomie modułu aplikacji uwzględnij bibliotekę AndroidX Core w wersji 1.9.0 lub nowszej:

   Groovy

   dependencies {
       def core_version = "1.19.0"
   
       // Java language implementation
       implementation "androidx.core:core:$core_version"
       // Kotlin
       implementation "androidx.core:core-ktx:$core_version"
   
       // To use RoleManagerCompat
       implementation "androidx.core:core-role:1.1.0"
   
       // To use the Animator APIs
       implementation "androidx.core:core-animation:1.0.0"
       // To test the Animator APIs
       androidTestImplementation "androidx.core:core-animation-testing:1.0.0"
   
       // Optional - To enable APIs that query the performance characteristics of GMS devices.
       implementation "androidx.core:core-performance:1.0.0"
   
       // Optional - to use ShortcutManagerCompat to donate shortcuts to be used by Google
       implementation "androidx.core:core-google-shortcuts:1.1.0"
   
       // Optional - to support backwards compatibility of RemoteViews
       implementation "androidx.core:core-remoteviews:1.1.0"
   
       // Optional - APIs for SplashScreen, including compatibility helpers on devices prior Android 12
       implementation "androidx.core:core-splashscreen:1.2.0"
   }

   Kotlin

   dependencies {
       val core_version = "1.19.0"
   
       // Java language implementation
       implementation("androidx.core:core:$core_version")
       // Kotlin
       implementation("androidx.core:core-ktx:$core_version")
   
       // To use RoleManagerCompat
       implementation("androidx.core:core-role:1.1.0")
   
       // To use the Animator APIs
       implementation("androidx.core:core-animation:1.0.0")
       // To test the Animator APIs
       androidTestImplementation("androidx.core:core-animation-testing:1.0.0")
   
       // Optional - To enable APIs that query the performance characteristics of GMS devices.
       implementation("androidx.core:core-performance:1.0.0")
   
       // Optional - to use ShortcutManagerCompat to donate shortcuts to be used by Google
       implementation("androidx.core:core-google-shortcuts:1.1.0")
   
       // Optional - to support backwards compatibility of RemoteViews
       implementation("androidx.core:core-remoteviews:1.1.0")
   
       // Optional - APIs for SplashScreen, including compatibility helpers on devices prior Android 12
       implementation("androidx.core:core-splashscreen:1.2.0")
   }

2. Utwórz instancję BroadcastReceiver:

   Kotlin

   val myBroadcastReceiver = MyBroadcastReceiver()
   

   Java

   MyBroadcastReceiver myBroadcastReceiver = new MyBroadcastReceiver();
   

3. Utwórz instancję IntentFilter:

   Kotlin

   val filter = IntentFilter("com.example.snippets.ACTION_UPDATE_DATA")
   

   Java

   IntentFilter filter = new IntentFilter("com.example.snippets.ACTION_UPDATE_DATA");
   

4. Wybierz, czy odbiornik ma być eksportowany i widoczny dla innych aplikacji na urządzeniu. Jeśli ten odbiornik nasłuchuje komunikatów rozgłoszeniowych wysyłanych przez system lub inne aplikacje – nawet inne aplikacje, które są Twoją własnością – użyj flagi RECEIVER_EXPORTED. Jeśli ten odbiornik nasłuchuje tylko komunikatów rozgłoszeniowych wysyłanych przez Twoją aplikację, użyj flagi RECEIVER_NOT_EXPORTED.

   Kotlin

   val listenToBroadcastsFromOtherApps = false
   val receiverFlags = if (listenToBroadcastsFromOtherApps) {
       ContextCompat.RECEIVER_EXPORTED
   } else {
       ContextCompat.RECEIVER_NOT_EXPORTED
   }
   BroadcastReceiverSnippets.kt
   

   Java

   boolean listenToBroadcastsFromOtherApps = false;
   int receiverFlags = listenToBroadcastsFromOtherApps
           ? ContextCompat.RECEIVER_EXPORTED
           : ContextCompat.RECEIVER_NOT_EXPORTED;
   BroadcastReceiverJavaSnippets.java
   

5. Zarejestruj odbiornik, wywołując registerReceiver():

   Kotlin

   ContextCompat.registerReceiver(context, myBroadcastReceiver, filter, receiverFlags)
   

   Java

   ContextCompat.registerReceiver(context, myBroadcastReceiver, filter, receiverFlags);
   

6. Aby przestać odbierać komunikaty rozgłoszeniowe, wywołaj unregisterReceiver(android.content.BroadcastReceiver). Pamiętaj, aby wyrejestrować odbiornik, gdy nie będzie już potrzebny lub gdy kontekst stanie się nieprawidłowy.

Wyrejestrowywanie odbiornika

Gdy odbiornik jest zarejestrowany, ma odniesienie do kontekstu, w którym został zarejestrowany. Może to spowodować wycieki pamięci, jeśli zarejestrowany zakres odbiornika przekracza zakres cyklu życia kontekstu. Może się to zdarzyć na przykład wtedy, gdy zarejestrujesz odbiornik w zakresie działania, ale zapomnisz go wyrejestrować, gdy system zniszczy działanie. Dlatego zawsze wyrejestrowuj odbiornik.

class MyActivity : ComponentActivity() {
    private val myBroadcastReceiver = MyBroadcastReceiver()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...
        ContextCompat.registerReceiver(this, myBroadcastReceiver, filter, receiverFlags)
        setContent { MyApp() }
    }

    override fun onDestroy() {
        super.onDestroy()
        // When you forget to unregister your receiver here, you're causing a leak!
        this.unregisterReceiver(myBroadcastReceiver)
    }
}
BroadcastReceiverSnippets.kt

class MyActivity extends ComponentActivity {
    MyBroadcastReceiver myBroadcastReceiver;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // ...
        ContextCompat.registerReceiver(this, myBroadcastReceiver, filter, receiverFlags);
        // Set content
    }
}
BroadcastReceiverJavaSnippets.java

Rejestrowanie odbiorników w najmniejszym zakresie

Odbiornik powinien być zarejestrowany tylko wtedy, gdy rzeczywiście interesuje Cię wynik. Wybierz najmniejszy możliwy zakres odbiornika:

• LifecycleResumeEffect lub metody cyklu życia działania onResume/onPause: odbiornik otrzymuje aktualizacje tylko wtedy, gdy aplikacja jest w stanie wznowienia.
• LifecycleStartEffect lub metody cyklu życia działania onStart/onStop: odbiornik otrzymuje aktualizacje tylko wtedy, gdy aplikacja jest w stanie wznowienia.
• DisposableEffect: odbiornik otrzymuje aktualizacje tylko wtedy, gdy element kompozycyjny znajduje się w drzewie kompozycji. Ten zakres nie jest powiązany z zakresem cyklu życia działania. Rozważ zarejestrowanie odbiornika w kontekście aplikacji. Element kompozycyjny może teoretycznie przetrwać zakres cyklu życia działania i spowodować wyciek pamięci.
• Działanie onCreate/onDestroy: odbiornik otrzymuje aktualizacje, gdy działanie jest w stanie utworzenia. Pamiętaj, aby wyrejestrować się w onDestroy(), a nie w onSaveInstanceState(Bundle), ponieważ ta metoda może nie zostać wywołana.
• Zakres niestandardowy: możesz na przykład zarejestrować odbiornik w zakresie ViewModel, aby przetrwał ponowne utworzenie działania. Pamiętaj, aby użyć kontekstu aplikacji do zarejestrowania odbiornika, ponieważ może on przetrwać zakres cyklu życia działania i spowodować wyciek pamięci.

Tworzenie elementów kompozycyjnych ze stanem i bez stanu

Compose ma elementy kompozycyjne ze stanem i bez stanu. Zarejestrowanie lub wyrejestrowanie odbiornika w elemencie kompozycyjnym sprawia, że staje się on elementem ze stanem. Element kompozycyjny nie jest funkcją deterministyczną, która renderuje tę samą treść, gdy przekazywane są te same parametry. Stan wewnętrzny może się zmieniać w zależności od wywołań zarejestrowanego odbiornika.

Zgodnie z najlepszymi praktykami w Compose zalecamy dzielenie elementów kompozycyjnych na wersje ze stanem i bez stanu. Dlatego zalecamy przeniesienie tworzenia odbiornika poza element kompozycyjny, aby stał się on elementem bez stanu:

@Composable
fun MyStatefulScreen() {
    val myBroadcastReceiver = remember { MyBroadcastReceiver() }
    val context = LocalContext.current
    LifecycleStartEffect(true) {
        // ...
        ContextCompat.registerReceiver(context, myBroadcastReceiver, filter, flags)
        onStopOrDispose { context.unregisterReceiver(myBroadcastReceiver) }
    }
    MyStatelessScreen()
}

@Composable
fun MyStatelessScreen() {
    // Implement your screen
}
BroadcastReceiverSnippets.kt

Odbiorniki zadeklarowane w pliku manifestu

Jeśli zadeklarujesz odbiornik w pliku manifestu, system uruchomi Twoją aplikację, gdy zostanie wysłany komunikat rozgłoszeniowy. Jeśli aplikacja nie jest jeszcze uruchomiona, system ją uruchomi.

Aby zadeklarować odbiornik w pliku manifestu, wykonaj te czynności:

1. W pliku manifestu aplikacji określ element <receiver>.

   <!-- If this receiver listens for broadcasts sent from the system or from
        other apps, even other apps that you own, set android:exported to "true". -->
   <receiver android:name=".MyBroadcastReceiver" android:exported="false">
       <intent-filter>
           <action android:name="com.example.snippets.ACTION_UPDATE_DATA" />
       </intent-filter>
   </receiver>
   AndroidManifest.xml
   

   Filtry intencji określają działania związane z komunikatami rozgłoszeniowymi, które subskrybuje odbiornik.

2. Utwórz podklasę BroadcastReceiver i zaimplementuj onReceive(Context, Intent). Odbiornik w poniższym przykładzie rejestruje i wyświetla zawartość komunikatu rozgłoszeniowego:

   Kotlin

   class MyBroadcastReceiver : BroadcastReceiver() {
   
       @Inject
       lateinit var dataRepository: DataRepository
   
       override fun onReceive(context: Context, intent: Intent) {
           if (intent.action == "com.example.snippets.ACTION_UPDATE_DATA") {
               val data = intent.getStringExtra("com.example.snippets.DATA") ?: "No data"
               // Do something with the data, for example send it to a data repository:
               dataRepository.updateData(data)
           }
       }
   }
   BroadcastReceiverSnippets.kt
   

   Java

   public static class MyBroadcastReceiver extends BroadcastReceiver {
   
       @Inject
       DataRepository dataRepository;
   
       @Override
       public void onReceive(Context context, Intent intent) {
           if (Objects.equals(intent.getAction(), "com.example.snippets.ACTION_UPDATE_DATA")) {
               String data = intent.getStringExtra("com.example.snippets.DATA");
               // Do something with the data, for example send it to a data repository:
               if (data != null) { dataRepository.updateData(data); }
           }
       }
   }
   BroadcastReceiverJavaSnippets.java
   

Menedżer pakietów systemu rejestruje odbiornik podczas instalowania aplikacji. Odbiornik staje się wtedy osobnym punktem wejścia do aplikacji, co oznacza, że jeśli aplikacja nie jest uruchomiona, system może ją uruchomić i dostarczyć komunikat rozgłoszeniowy.

System tworzy nowy BroadcastReceiver obiekt komponentu, aby obsługiwać każdy otrzymany komunikat rozgłoszeniowy. Ten obiekt jest ważny tylko przez czas trwania wywołania onReceive(Context, Intent). Gdy kod powróci z tej metody, system uzna, że komponent nie jest już aktywny.

Wpływ na stan procesu

To, czy BroadcastReceiver działa, czy nie, wpływa na proces, w którym się znajduje , co może zmienić prawdopodobieństwo jego zakończenia przez system. Proces działający na pierwszym planie wykonuje metodę onReceive() odbiornika. System uruchamia proces, z wyjątkiem sytuacji, gdy występuje ekstremalne obciążenie pamięci.

Po wywołaniu onReceive() system dezaktywuje BroadcastReceiver. Znaczenie procesu hosta odbiornika zależy od jego komponentów aplikacji. Jeśli ten proces hostuje tylko odbiornik zadeklarowany w pliku manifestu, system może go zakończyć po wywołaniu onReceive(), aby zwolnić zasoby dla innych, bardziej krytycznych procesów. Jest to typowe w przypadku aplikacji, z których użytkownik nigdy nie korzystał lub nie korzystał ostatnio.

Dlatego odbiorniki nie powinny inicjować długotrwałych wątków w tle. Po wywołaniu onReceive() system może w dowolnym momencie zatrzymać proces, aby odzyskać pamięć, co spowoduje zakończenie utworzonego wątku. Aby utrzymać proces przy życiu, zaplanuj JobService z odbiornika za pomocą JobScheduler, aby system wiedział, że proces nadal działa. Więcej informacji znajdziesz w artykule Przegląd pracy w tle.

Wysyłanie komunikatów rozgłoszeniowych

Android udostępnia 2 sposoby wysyłania komunikatów rozgłoszeniowych przez aplikacje:

• Metoda sendOrderedBroadcast(Intent, String) wysyła komunikaty rozgłoszeniowe do 1 odbiornika naraz. Gdy każdy odbiornik jest wykonywany po kolei, może przekazywać wynik do następnego odbiornika. Może też całkowicie przerwać komunikat rozgłoszeniowy, aby nie dotarł do innych odbiorników. Możesz kontrolować kolejność, w jakiej odbiorniki są uruchamiane w ramach tego samego procesu aplikacji. Aby to zrobić, użyj atrybutu android:priority pasującego filtra intencji. Odbiorniki o tym samym priorytecie są uruchamiane w dowolnej kolejności.
• Metoda sendBroadcast(Intent) wysyła komunikaty rozgłoszeniowe do wszystkich odbiorników w nieokreślonej kolejności. Nazywa się to normalnym komunikatem rozgłoszeniowym. Jest to bardziej wydajne, ale oznacza, że odbiorniki nie mogą odczytywać wyników z innych odbiorników, propagować danych otrzymanych z komunikatu rozgłoszeniowego ani przerywać komunikatu rozgłoszeniowego.

Ten fragment kodu pokazuje, jak wysłać komunikat rozgłoszeniowy, tworząc intencję i wywołując sendBroadcast(Intent).

val intent = Intent("com.example.snippets.ACTION_UPDATE_DATA").apply {
    putExtra("com.example.snippets.DATA", newData)
    setPackage("com.example.snippets")
}
context.sendBroadcast(intent)
BroadcastReceiverSnippets.kt

Intent intent = new Intent("com.example.snippets.ACTION_UPDATE_DATA");
intent.putExtra("com.example.snippets.DATA", newData);
intent.setPackage("com.example.snippets");
context.sendBroadcast(intent);
BroadcastReceiverJavaSnippets.java

Komunikat rozgłoszeniowy jest opakowany w obiekt Intent. Ciąg znaków action intencji musi zawierać składnię nazwy pakietu Java aplikacji i jednoznacznie identyfikować zdarzenie komunikatu rozgłoszeniowego. Możesz dołączyć dodatkowe informacje do intencji za pomocą putExtra(String, Bundle). Możesz też ograniczyć komunikat rozgłoszeniowy do zestawu aplikacji w tej samej organizacji, wywołując setPackage(String) w intencji.

Ograniczanie komunikatów rozgłoszeniowych za pomocą uprawnień

Uprawnienia pozwalają ograniczyć komunikaty rozgłoszeniowe do zestawu aplikacji, które mają określone uprawnienia. Możesz wymusić ograniczenia dotyczące nadawcy lub odbiorcy komunikatu rozgłoszeniowego.

Wysyłanie komunikatów rozgłoszeniowych z uprawnieniami

Gdy wywołujesz sendBroadcast(Intent, String) lub sendOrderedBroadcast(Intent, String, BroadcastReceiver, Handler, int, String, Bundle) , możesz określić parametr uprawnień. Komunikat rozgłoszeniowy mogą odbierać tylko odbiorniki, które poprosiły o to uprawnienie za pomocą tagu <uses-permission> w pliku manifestu. Jeśli uprawnienie jest niebezpieczne, musisz je przyznać, zanim odbiornik będzie mógł odbierać komunikat rozgłoszeniowy. Na przykład ten kod wysyła komunikat rozgłoszeniowy z uprawnieniem:

context.sendBroadcast(intent, android.Manifest.permission.ACCESS_COARSE_LOCATION)

context.sendBroadcast(intent, android.Manifest.permission.ACCESS_COARSE_LOCATION);

Aby odbierać komunikat rozgłoszeniowy, aplikacja odbierająca musi poprosić o uprawnienie w ten sposób:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

Możesz określić istniejące uprawnienie systemowe, takie jak BLUETOOTH_CONNECT lub zdefiniować uprawnienie niestandardowe za pomocą elementu <permission>. Więcej informacji o uprawnieniach i bezpieczeństwie znajdziesz w artykule Uprawnienia systemowe.

Odbieranie komunikatów rozgłoszeniowych z uprawnieniami

Jeśli podczas rejestrowania odbiornika określisz parametr uprawnień (za pomocą registerReceiver(BroadcastReceiver, IntentFilter, String, Handler) lub w <receiver> tagu w pliku manifestu), tylko nadawcy, którzy poprosili o uprawnienie za pomocą <uses-permission> tagu w swoim pliku manifestu, będą mogli wysyłać intencję do odbiornika. Jeśli uprawnienie jest niebezpieczne, nadawca musi też je otrzymać.

Załóżmy na przykład, że aplikacja odbierająca ma odbiornik zadeklarowany w pliku manifestu w ten sposób:

<!-- If this receiver listens for broadcasts sent from the system or from
     other apps, even other apps that you own, set android:exported to "true". -->
<receiver
    android:name=".MyBroadcastReceiverWithPermission"
    android:permission="android.permission.ACCESS_COARSE_LOCATION"
    android:exported="true">
    <intent-filter>
        <action android:name="com.example.snippets.ACTION_UPDATE_DATA" />
    </intent-filter>
</receiver>
AndroidManifest.xml

Lub aplikacja odbierająca ma odbiornik zarejestrowany w kontekście w ten sposób:

ContextCompat.registerReceiver(
    context, myBroadcastReceiver, filter,
    android.Manifest.permission.ACCESS_COARSE_LOCATION,
    null, // scheduler that defines thread, null means run on main thread
    receiverFlags
)
BroadcastReceiverSnippets.kt

ContextCompat.registerReceiver(
        context, myBroadcastReceiver, filter,
        android.Manifest.permission.ACCESS_COARSE_LOCATION,
        null, // scheduler that defines thread, null means run on main thread
        receiverFlags
);
BroadcastReceiverJavaSnippets.java

Aby móc wysyłać komunikaty rozgłoszeniowe do tych odbiorników, aplikacja wysyłająca musi poprosić o uprawnienie w ten sposób:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

Bezpieczeństwo

Oto kilka kwestii związanych z bezpieczeństwem wysyłania i odbierania komunikatów rozgłoszeniowych:

• Jeśli wiele aplikacji zarejestrowało się w pliku manifestu, aby odbierać ten sam komunikat rozgłoszeniowy, może to spowodować uruchomienie przez system wielu aplikacji, co będzie miało znaczący wpływ na wydajność urządzenia i wygodę użytkownika. Aby tego uniknąć, zamiast deklaracji w pliku manifestu używaj rejestracji w kontekście. Czasami sam system Android wymusza używanie odbiorników zarejestrowanych w kontekście. Na przykład komunikat rozgłoszeniowy CONNECTIVITY_ACTION jest dostarczany tylko do odbiorników zarejestrowanych w kontekście.

• Nie wysyłaj informacji poufnych za pomocą intencji ogólnej. Każda aplikacja może odczytać te informacje, jeśli zarejestruje się, aby odbierać komunikat rozgłoszeniowy. Istnieją 3 sposoby kontrolowania, kto może odbierać Twoje komunikaty rozgłoszeniowe:

  • Podczas wysyłania komunikatu rozgłoszeniowego możesz określić uprawnienie.
  • W Androidzie 4.0 (poziom interfejsu API 14) i nowszych wersjach podczas wysyłania komunikatu rozgłoszeniowego możesz określić pakiet za pomocą setPackage(String). System ogranicza komunikat rozgłoszeniowy do zestawu aplikacji, które pasują do pakietu.

• Gdy zarejestrujesz odbiornik, każda aplikacja może wysyłać do odbiornika Twojej aplikacji potencjalnie złośliwe komunikaty rozgłoszeniowe. Istnieje kilka sposobów ograniczenia komunikatów rozgłoszeniowych, które otrzymuje Twoja aplikacja:

  • Podczas rejestrowania odbiornika możesz określić uprawnienie.
  • W przypadku odbiorników zadeklarowanych w pliku manifestu możesz ustawić w nim atrybut android:exported na „false”. Odbiornik nie będzie otrzymywać komunikatów rozgłoszeniowych ze źródeł spoza aplikacji.

• Przestrzeń nazw działań związanych z komunikatami rozgłoszeniowymi jest globalna. Upewnij się, że nazwy działań i inne ciągi znaków są zapisane w przestrzeni nazw, której jesteś właścicielem. W przeciwnym razie możesz nieumyślnie wejść w konflikt z innymi aplikacjami.

• Ponieważ metoda onReceive(Context, Intent) odbiornika jest uruchamiana w wątku głównym, powinna być wykonywana i zwracać wynik szybko. Jeśli musisz wykonać długotrwałą pracę, uważaj na tworzenie wątków lub uruchamianie usług w tle, ponieważ po powrocie z onReceive() system może zakończyć cały proces. Więcej informacji znajdziesz w sekcji Wpływ na stan procesu. Aby wykonać długotrwałą pracę, zalecamy:

  • Wywołanie goAsync() w metodzie onReceive() odbiornika i przekazanie BroadcastReceiver.PendingResult do wątku w tle. Dzięki temu komunikat rozgłoszeniowy pozostanie aktywny po powrocie z onReceive(). Nawet w tym przypadku system oczekuje jednak, że bardzo szybko (w ciągu 10 sekund) zakończysz pracę z komunikatem rozgłoszeniowym. Umożliwia to przeniesienie pracy do innego wątku, aby uniknąć zakłóceń w wątku głównym.
  • Zaplanowanie zadania za pomocą JobScheduler. Więcej informacji znajdziesz w artykule Inteligentne planowanie zadań.

• Nie uruchamiaj działań z odbiorników, ponieważ może to powodować zakłócenia w działaniu aplikacji, zwłaszcza jeśli jest więcej niż 1 odbiornik. Zamiast tego rozważ wyświetlenie powiadomienia.