Intent
to obiekt wiadomości, którego możesz użyć do żądania wykonania działania przez inny komponent aplikacji.
Chociaż intencje ułatwiają komunikację między komponentami na kilka sposobów, istnieją 3 podstawowe przypadki użycia:
- Rozpoczynanie aktywności
Obiekt
Activity
reprezentuje pojedynczy ekran w aplikacji. Możesz uruchomić nową instancjęActivity
, przekazując obiektIntent
dostartActivity()
. ElementIntent
opisuje aktywność do uruchomienia i zawiera wszystkie niezbędne dane.Jeśli chcesz otrzymać wynik po zakończeniu aktywności, zadzwoń pod numer
startActivityForResult()
. Twoja aktywność otrzyma wynik jako osobny obiektIntent
w wywołaniu zwrotnymonActivityResult()
. Więcej informacji znajdziesz w przewodniku Aktywności. - Rozpoczynanie usługi
Service
to komponent, który wykonuje operacje w tle bez użycia interfejsu. W Androidzie 5.0 (poziom interfejsu API 21) i nowszych możesz uruchomić usługę za pomocąJobScheduler
. Więcej informacji oJobScheduler
znajdziesz na stronieAPI-reference documentation
.W przypadku wersji Androida starszych niż 5.0 (poziom interfejsu API 21) możesz uruchamiać usługę za pomocą metod klasy
Service
. Możesz uruchomić usługę, aby wykonać jednorazową operację (np. pobrać plik), przekazującIntent
dostartService()
.Intent
opisuje usługę, która uruchamia i przenosi wszystkie niezbędne dane.Jeśli usługa jest zaprojektowana z interfejsem klient-serwer, możesz ją powiązać z innym komponentem, przekazując obiekt
Intent
do funkcjibindService()
. Więcej informacji znajdziesz w przewodniku po usługach. - Wysyłanie transmisji
Wiadomość rozgłaszana to wiadomość, którą może otrzymać dowolna aplikacja. System wysyła różne transmisje dotyczące zdarzeń systemowych, np. uruchamiania systemu lub ładowania urządzenia. Możesz przesyłać transmisję do innych aplikacji, przekazując wartość
Intent
dosendBroadcast()
lubsendOrderedBroadcast()
.
W dalszej części tej strony wyjaśniamy, jak działają intencje i jak z nich korzystać. Informacje pokrewne znajdziesz w sekcjach Korzystanie z innych aplikacji i Udostępnianie treści.
Typy intencji
Istnieją 2 rodzaje intencji:
- Jasne intencje określają, który komponent której aplikacji ma spełnić intencję, przez podanie pełnego
ComponentName
. Zazwyczaj do uruchamiania komponentu w własnej aplikacji używasz wyraźnego zamiaru, ponieważ znasz nazwę klasy aktywności lub usługi, którą chcesz uruchomić. Możesz na przykład uruchomić nową aktywność w aplikacji w odpowiedzi na działanie użytkownika lub uruchomić usługę, aby pobrać plik w tle. - Intencje ogólne nie określają nazwy konkretnego komponentu, tylko deklarują ogólne działanie do wykonania, które umożliwia komponentowi z innej aplikacji jego obsługę. Jeśli na przykład chcesz wyświetlić użytkownikowi lokalizację na mapie, możesz użyć domyślnego zamiaru, aby poprosić inną aplikację o wyświetlenie określonej lokalizacji na mapie.
Rysunek 1 przedstawia, jak intencja jest używana podczas uruchamiania aktywności. Gdy obiekt Intent
jednoznacznie określa określony komponent aktywności, system od razu go uruchamia.
Gdy używasz intencji domyślnej, system Android znajduje odpowiedni komponent do uruchomienia, porównując zawartość intencji z filtrami intencji zadeklarowanymi w pliku manifestu innych aplikacji na urządzeniu. Jeśli intencja pasuje do filtra intencji, system uruchamia komponent i przekazuje mu obiekt Intent
. Jeśli kilka filtrów intencji jest zgodnych, system wyświetli okno dialogowe, aby użytkownik mógł wybrać aplikację, której ma użyć.
Filtr intencji to wyrażenie w pliku manifestu aplikacji, które określa typy intencji, które komponent chce otrzymywać. Na przykład deklarując filtr intencji dla aktywności, umożliwiasz innym aplikacjom bezpośrednie uruchamianie Twojej aktywności z określonym rodzajem intencji. Podobnie, jeśli nie zadeklarujesz żadnych filtrów intencji dla działania, będzie można je uruchomić tylko z wyraźną intencją.
Uwaga: aby zapewnić bezpieczeństwo aplikacji, zawsze używaj jawnej intencji podczas uruchamiania Service
i nie deklaruj filtrów intencji dla swoich usług. Używanie do uruchomienia usługi domyślnego zamiaru jest zagrożeniem dla bezpieczeństwa, ponieważ nie można mieć pewności, która usługa odpowie na zamiar, a użytkownik nie widzi, która usługa się uruchamia. Począwszy od Androida 5.0 (poziom interfejsu API 21) system zgłasza wyjątek, jeśli wywołasz bindService()
z użyciem niejawnej intencji.
Tworzenie intencji
Obiekt Intent
zawiera informacje, na podstawie których system Android określa, który komponent należy uruchomić (np. dokładną nazwę komponentu lub jego kategorię, który powinien otrzymać intencję), a także informacje, których komponent odbiorcy używa do prawidłowego wykonania działania (np. nazwę i dane, na które należy podjąć działanie).
Główne informacje zawarte w pliku Intent
:
- Nazwa komponentu
- Nazwa komponentu do uruchomienia.
Jest to element opcjonalny, ale kluczowa informacja, która sprawia, że chęć jest wyraźna, co oznacza, że chęć powinna być dostarczana tylko do komponentu aplikacji zdefiniowanego przez nazwę komponentu. Bez nazwy komponentu intencja jest domyślna, a system decyduje, który komponent powinien ją otrzymać na podstawie innych informacji o intencji (takich jak działanie, dane i kategoria, opisane poniżej). Jeśli chcesz uruchomić konkretny komponent w aplikacji, musisz podać jego nazwę.
Uwaga: podczas uruchamiania
Service
zawsze podawaj nazwę komponentu. W przeciwnym razie nie będziesz mieć pewności, która usługa odpowie na intencję, a użytkownik nie będzie widzieć, która usługa się uruchamia.To pole
Intent
jest obiektemComponentName
, który możesz określić, używając pełnej i jednoznacznej nazwy klasy komponentu docelowego z nazwą pakietu aplikacji, np.com.example.ExampleActivity
. Nazwę komponentu możesz ustawić za pomocąsetComponent()
,setClass()
,setClassName()
lub konstruktoraIntent
. - Działanie
- Ciąg znaków określający ogólne działanie do wykonania (np. wyświetl lub wybierz).
W przypadku intencji dotyczącej transmisji jest to działanie, które miało miejsce i jest zgłaszane. Działanie w dużej mierze określa, jak sformułowana jest reszta intencji, w szczególności informacje zawarte w danych i elementach dodatkowych.
Możesz określić własne działania do użycia przez intencje w aplikacji (lub do użycia przez inne aplikacje do wywoływania komponentów w aplikacji), ale zwykle określasz stałe działania zdefiniowane przez klasę
Intent
lub inne klasy frameworka. Oto kilka najczęstszych sposobów na rozpoczęcie aktywności:ACTION_VIEW
- Używaj tego działania w intencji z
startActivity()
, gdy masz informacje, które aktywność może wyświetlić użytkownikowi, np. zdjęcie do wyświetlenia w aplikacji galerii lub adres do wyświetlenia w aplikacji map. ACTION_SEND
- Zwany też zamierzaniem udostępniania. Należy go używać w zamierzaniu
startActivity()
, gdy masz dane, które użytkownik może udostępnić za pomocą innej aplikacji, np. aplikacji pocztowej lub aplikacji do udostępniania w mediach społecznościowych.
Więcej stałych definiujących ogólne działania znajdziesz w dokumentacji klasy
Intent
. Inne działania są zdefiniowane w innych miejscach w ramach platformy Androida, np. wSettings
dla działań, które powodują otwarcie określonych ekranów w systemowej aplikacji Ustawienia.Działanie związane z intencją możesz określić za pomocą funkcji
setAction()
lub konstruktoraIntent
.Jeśli zdefiniujesz własne działania, pamiętaj o dodaniu nazwy pakietu aplikacji jako prefiksu, jak w tym przykładzie:
Kotlin
const val ACTION_TIMETRAVEL = "com.example.action.TIMETRAVEL"
Java
static final String ACTION_TIMETRAVEL = "com.example.action.TIMETRAVEL";
- Dane
- Identyfikator URI (obiekt
Uri
), który odwołuje się do danych, na które ma zostać wykonane działanie, lub typ MIME tych danych. Typ danych jest zwykle określany przez działanie związane z zamiarem. Jeśli na przykład działanie toACTION_EDIT
, dane powinny zawierać URI dokumentu do edycji.Przy tworzeniu intencji często ważne jest, aby oprócz identyfikatora URI określić typ danych (jej typ MIME). Na przykład działanie, które może wyświetlać obrazy, prawdopodobnie nie odtworzy pliku audio, chociaż formaty identyfikatora URI mogą być podobne. Określanie typu MIME danych pomaga systemowi Android znaleźć najlepszy komponent do odbioru Twojej intencji. Czasami typ MIME można jednak określić na podstawie identyfikatora URI, zwłaszcza gdy dane są identyfikatorem URI
content:
. Identyfikator URIcontent:
wskazuje, że dane znajdują się na urządzeniu i są kontrolowane przezContentProvider
, co powoduje, że typ MIME danych jest widoczny dla systemu.Aby ustawić tylko identyfikator URI danych, wywołaj funkcję
setData()
. Aby ustawić tylko typ MIME, wywołaj funkcjęsetType()
. W razie potrzeby możesz ustawić oba te parametry za pomocą parametrusetDataAndType()
.Uwaga: jeśli chcesz ustawić zarówno URI, jak i typ MIME, nie wywołuj funkcji
setData()
anisetType()
, ponieważ każda z nich anuluje wartość drugiej. Do ustawiania typu URI i MIME zawsze używaj właściwościsetDataAndType()
. - Kategoria
- Ciąg tekstowy zawierający dodatkowe informacje o rodzaju komponentu, który powinien obsłużyć intencję. W intencji można umieścić dowolną liczbę opisów kategorii, ale większość intencji nie wymaga kategorii.
Oto kilka typowych kategorii:
CATEGORY_BROWSABLE
- Aktywność docelowa może być uruchamiana przez przeglądarkę internetową w celu wyświetlenia danych, do których odwołuje się link, np. obraz lub wiadomość e-mail.
CATEGORY_LAUNCHER
- Aktywność jest początkową aktywnością zadania i jest wymieniona w Menu z aplikacjami systemu.
Pełną listę kategorii znajdziesz w opisie klasy
Intent
.Kategorię możesz określić za pomocą tagu
addCategory()
.
Wymienione powyżej właściwości (nazwa komponentu, działanie, dane i kategoria) stanowią cechy definiujące intencję. Dzięki odczytaniu tych właściwości system Android może określić, który komponent aplikacji ma uruchomić. Może ona jednak zawierać dodatkowe informacje, które nie wpływają na sposób jej przekształcania w element aplikacji. Intencja może też dostarczać te informacje:
- Dodatki
- Pary klucz-wartość zawierające dodatkowe informacje wymagane do wykonania żądanego działania.
Niektóre działania używają określonych rodzajów identyfikatorów URI danych, tak samo niektóre działania wykorzystują też określone dodatki.
Dodatkowe dane możesz dodawać za pomocą różnych metod
putExtra()
, z których każda przyjmuje 2 parametry: nazwę klucza i wartość. Możesz też utworzyć obiektBundle
ze wszystkimi dodatkowymi danymi, a potem umieścićBundle
w obiekcieIntent
za pomocąputExtras()
.Podczas tworzenia intencji wysyłania e-maila za pomocą funkcji
ACTION_SEND
możesz określić odbiorcę to za pomocą kluczaEXTRA_EMAIL
, a także temat za pomocą kluczaEXTRA_SUBJECT
.Klasa
Intent
definiuje wiele stałychEXTRA_*
dla ujednoliconych typów danych. Jeśli musisz zadeklarować dodatkowe klucze (dla intencji, które otrzymuje Twoja aplikacja), pamiętaj, aby dołączyć nazwę pakietu aplikacji jako prefiks, jak w tym przykładzie:Kotlin
const val EXTRA_GIGAWATTS = "com.example.EXTRA_GIGAWATTS"
Java
static final String EXTRA_GIGAWATTS = "com.example.EXTRA_GIGAWATTS";
Uwaga: nie używaj danych
Parcelable
aniSerializable
podczas wysyłania intencji, która według Ciebie powinna otrzymać inna aplikacja. Jeśli aplikacja próbuje uzyskać dostęp do danych w obiekcieBundle
, ale nie ma dostępu do klasy parcelowanej lub serializowanej, system zgłaszaRuntimeException
. - Flagi
- Flagi są zdefiniowane w klasie
Intent
, które działają jako metadane intencji. Flagi mogą przekazywać systemowi Android instrukcje dotyczące uruchamiania aktywności (np. do którego zadania powinna należeć dana aktywność) oraz sposobu postępowania z aktywność po jej uruchomieniu (np. czy powinna być umieszczona na liście ostatnich aktywności).Więcej informacji znajdziesz w metodzie
setFlags()
.
Przykładowa intencja bezpośrednia
Wyraźna intencja to intencja, której używasz do uruchamiania określonego komponentu aplikacji, np. określonej aktywności lub usługi w aplikacji. Aby utworzyć wyraźną intencję, zdefiniuj nazwę komponentu dla obiektu Intent
. Pozostałe właściwości intencji są opcjonalne.
Jeśli na przykład masz w aplikacji utworzoną usługę o nazwie DownloadService
, która ma pobierać plik z internetu, możesz ją uruchomić za pomocą tego kodu:
Kotlin
// Executed in an Activity, so 'this' is theContext
// The fileUrl is a string URL, such as "http://www.example.com/image.png" val downloadIntent = Intent(this, DownloadService::class.java).apply { data =Uri.parse
(fileUrl) } startService(downloadIntent)
Java
// Executed in an Activity, so 'this' is theContext
// The fileUrl is a string URL, such as "http://www.example.com/image.png" Intent downloadIntent = new Intent(this, DownloadService.class); downloadIntent.setData(Uri.parse
(fileUrl)); startService(downloadIntent);
Konstruktor Intent(Context, Class)
dostarcza aplikacji Context
, a komponentowi obiekt Class
. W związku z tym ten zamiar wyraźnie uruchamia klasę DownloadService
w aplikacji.
Więcej informacji o tworzeniu i uruchamianiu usługi znajdziesz w przewodniku Usługi.
Przykład intencji ogólnej
Intencja niejawna określa działanie, które może wywołać na urządzeniu dowolną aplikację mogącą wykonać to działanie. Korzystanie z intencji niejawnej przydaje się, gdy aplikacja nie może wykonać danego działania, a inne aplikacje prawdopodobnie mogą to robić i chcesz, aby to użytkownik wybrał aplikację, której chce użyć.
Jeśli na przykład masz treści, które użytkownik ma udostępnić innym osobom, utwórz intencję z działaniem ACTION_SEND
i dodaj dodatkowe informacje określające treści do udostępnienia. Gdy wywołasz intent startActivity()
, użytkownik może wybrać aplikację, za pomocą której udostępni treści.
Kotlin
// Create the text message with a string. val sendIntent = Intent().apply { action = Intent.ACTION_SEND putExtra(Intent.EXTRA_TEXT, textMessage) type = "text/plain" } // Try to invoke the intent. try { startActivity(sendIntent) } catch (e: ActivityNotFoundException) { // Define what your app should do if no activity can handle the intent. }
Java
// Create the text message with a string. Intent sendIntent = new Intent(); sendIntent.setAction(Intent.ACTION_SEND); sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage); sendIntent.setType("text/plain"); // Try to invoke the intent. try { startActivity(sendIntent); } catch (ActivityNotFoundException e) { // Define what your app should do if no activity can handle the intent. }
Gdy wywołana zostanie metoda startActivity()
, system sprawdza wszystkie zainstalowane aplikacje, aby określić, które z nich mogą obsłużyć ten rodzaj zamiaru (zamiar z działaniem ACTION_SEND
i danymi w formacie „text/plain”). Jeśli jest tylko jedna aplikacja, która może obsłużyć tę czynność, otwiera się ona natychmiast i otrzymuje intencję. Jeśli inne aplikacje nie są w stanie go obsłużyć, może wychwytywać błąd ActivityNotFoundException
. Jeśli wiele działań akceptuje ten zamiar, system wyświetla okno podobne do tego na rysunku 2, aby użytkownik mógł wybrać aplikację.
Więcej informacji o uruchamianiu innych aplikacji znajdziesz w przewodniku przesyłania użytkownika do innej aplikacji.
Wymuszenie wyboru aplikacji
Jeśli istnieje więcej niż 1 aplikacja, która reaguje na Twoją domyślną intencję, użytkownik może wybrać aplikację, której ma używać domyślnie. Możliwość wybrania domyślnej aplikacji jest przydatna podczas wykonywania czynności, do której użytkownik prawdopodobnie chce używać tej samej aplikacji za każdym razem, np. otwierania strony internetowej (użytkownicy często preferują tylko jedną przeglądarkę internetową).
Jeśli jednak na daną intencję może odpowiadać kilka aplikacji i użytkownik może chcieć za każdym razem korzystać z innej, wyświetl okno wyboru. W oknie wyboru użytkownik musi wybrać aplikację, której ma użyć do wykonania danej czynności (nie może wybrać aplikacji domyślnej). Jeśli na przykład Twoja aplikacja wykonuje działanie „udostępnianie” za pomocą działania ACTION_SEND
, użytkownicy mogą chcieć udostępnić plik za pomocą innej aplikacji w zależności od bieżącej sytuacji. Z tego powodu zawsze używaj okna wyboru, jak pokazano na rysunku 2.
Aby wyświetlić selektor, utwórz obiekt Intent
za pomocą funkcji createChooser()
i przenieś go do funkcji startActivity()
, jak pokazano w tym przykładzie.
W tym przykładzie wyświetla się okno z listą aplikacji, które odpowiadają na intencję przekazaną do metody createChooser()
i używają podanego tekstu jako tytułu okna.
Kotlin
val sendIntent = Intent(Intent.ACTION_SEND) ... // Always use string resources for UI text. // This says something like "Share this photo with" val title: String = resources.getString(R.string.chooser_title) // Create intent to show the chooser dialog val chooser: Intent = Intent.createChooser(sendIntent, title) // Verify the original intent will resolve to at least one activity if (sendIntent.resolveActivity(packageManager) != null) { startActivity(chooser) }
Java
Intent sendIntent = new Intent(Intent.ACTION_SEND); ... // Always use string resources for UI text. // This says something like "Share this photo with" String title = getResources().getString(R.string.chooser_title); // Create intent to show the chooser dialog Intent chooser = Intent.createChooser(sendIntent, title); // Verify the original intent will resolve to at least one activity if (sendIntent.resolveActivity(getPackageManager()) != null) { startActivity(chooser); }
Wykrywanie uruchamiania niebezpiecznych intencji
Aplikacja może uruchamiać intencje, aby nawigować między komponentami w aplikacji lub wykonać działanie w imieniu innej aplikacji. Aby zwiększyć bezpieczeństwo platformy, Android 12 (poziom interfejsu API 31) i nowsze wersje zawierają funkcję debugowania, która ostrzega, jeśli aplikacja uruchamia niebezpieczną intencję. Na przykład aplikacja może przeprowadzić niebezpieczne uruchomienie intencji zagnieżdżonej, która jest przekazywana jako dodatkowa intencja w innej intencji.
Jeśli aplikacja wykonuje oba te działania, system wykryje niebezpieczne uruchomienie intencjonalnego wywołania i wystąpi naruszenie Trybu rygorystycznego:
- Aplikacja rozpakowuje zagnieżdżoną intencję z elementów dodatkowych dostarczonej intencji.
- Aplikacja natychmiast uruchamia komponent aplikacji, używając tej zagnieżdżonej intencji, na przykład przekazując ją do
startActivity()
,startService()
lubbindService()
.
Więcej informacji o tym, jak zidentyfikować tę sytuację i wprowadzić zmiany w aplikacji, znajdziesz w poście na blogu na temat zagnieżdżania poleceń na Androidzie na Medium.
Sprawdzanie, czy nie są uruchamiane niebezpieczne intencje
Aby sprawdzić, czy w aplikacji nie są uruchamiane niebezpieczne intencje, podczas konfigurowania VmPolicy
wywołaj funkcję detectUnsafeIntentLaunch()
, jak pokazano w tym fragmencie kodu. Jeśli aplikacja wykryje naruszenie zasad StrictMode, możesz zatrzymać wykonywanie aplikacji, aby chronić informacje potencjalnie poufne.
Kotlin
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() // Other StrictMode checks that you've previously added. // ... .detectUnsafeIntentLaunch() .penaltyLog() // Consider also adding penaltyDeath() .build()) }
Java
protected void onCreate() { StrictMode.setVmPolicy(new VmPolicy.Builder() // Other StrictMode checks that you've previously added. // ... .detectUnsafeIntentLaunch() .penaltyLog() // Consider also adding penaltyDeath() .build()); }
Korzystaj z intencji bardziej odpowiedzialnie
Aby zminimalizować ryzyko uruchomienia niebezpiecznej intencji i naruszenia zasad trybu ścisłego, stosuj te sprawdzone metody.
Skopiuj tylko najważniejsze dodatki w intencjach i wykonaj niezbędne czyszczenie i weryfikację. Aplikacja może skopiować dodatkowe informacje z jednej intencji do innej, która służy do uruchamiania nowego komponentu. Dzieje się tak, gdy aplikacja wywołuje putExtras(Intent)
lub putExtras(Bundle)
.
Jeśli Twoja aplikacja wykonuje jedną z tych operacji, skopiuj tylko dodatkowe elementy, których oczekuje komponent odbierający. Jeśli inny zamiar (który otrzymuje kopię) uruchamia komponent, który nie został wyeksportowany, przed skopiowaniem dodatkowych informacji do zamiaru, który uruchamia komponent, należy je wyczyścić i sprawdzić.
Nie eksportuj niepotrzebnie komponentów aplikacji. Jeśli na przykład chcesz uruchomić komponent aplikacji za pomocą wewnętrznej zanurzonej intencji, ustaw atrybut android:exported
tego komponentu na false
.
Zamiast zagnieżdżonego zamiaru używaj PendingIntent
. Dzięki temu, gdy inna aplikacja rozpakuje pakiet PendingIntent
zawierający Intent
, może uruchomić PendingIntent
, korzystając z tożsamości Twojej aplikacji. Ta konfiguracja umożliwia innej aplikacji bezpieczne uruchamianie w Twojej aplikacji dowolnego komponentu, w tym niewyeksportowanego.
Schemat na rysunku 2 pokazuje, jak system przekazuje kontrolę z Twojej aplikacji (klienta) do innej aplikacji (usługi) i z powrotem do Twojej aplikacji:
- Twoja aplikacja tworzy intencję, która wywołuje aktywność w innej aplikacji. W ramach tej intencji dodajesz obiekt
PendingIntent
jako dodatkowy. Ta oczekująca intencja wywołuje komponent w aplikacji, który nie jest eksportowany. - Po otrzymaniu intencji aplikacji druga aplikacja wyodrębnia zagnieżdżony obiekt
PendingIntent
. - Inna aplikacja wywołuje metodę
send()
obiektuPendingIntent
. - Po przekazaniu kontroli z powrotem do aplikacji system wywołuje oczekującą intencję, wykorzystując kontekst aplikacji.
Rysunek 2. Schemat komunikacji między aplikacjami, gdy używana jest zagnieżdżona oczekująca intencja.
Odbieranie intencji ogólnej
Aby określić, które ukryte intencje może otrzymywać Twoja aplikacja, zadeklaruj co najmniej 1 filtr intencji dla każdego z jej komponentów za pomocą elementu <intent-filter>
w pliku manifestu.
Każdy filtr intencji określa typy intencji, które akceptuje, na podstawie działania, danych i kategorii intencji. System dostarcza domyślną intencję do komponentu aplikacji tylko wtedy, gdy intencja może przejść przez jeden z filtrów intencji.
Uwaga: wyraźna intencja jest zawsze dostarczana do celu niezależnie od filtrów intencji zadeklarowanych przez komponent.
Komponent aplikacji powinien zadeklarować osobne filtry dla każdego unikalnego zadania.
Na przykład jedna aktywność w aplikacji galerii obrazów może mieć 2 filtry: jeden filtr do wyświetlania obrazu i drugi do edycji obrazu. Gdy aktywność się rozpoczyna, sprawdza Intent
i decyduje, jak się zachować na podstawie informacji w Intent
(np. czy ma wyświetlić elementy sterujące edytora).
Każdy filtr intencji jest zdefiniowany przez element <intent-filter>
w pliku manifestu aplikacji, zagnieżdżony w odpowiednim komponencie aplikacji (np. w elemencie <activity>
).
W każdym komponencie aplikacji, który zawiera element <intent-filter>
, wyraźnie określ wartość atrybutu android:exported
.
Ten atrybut wskazuje, czy składnik aplikacji jest dostępny dla innych aplikacji. W niektórych sytuacjach, np. gdy filtry intencji obejmują kategorię LAUNCHER
, warto ustawić ten atrybut na true
. W przeciwnym razie bezpieczniej jest ustawić wartość tego atrybutu na false
.
Ostrzeżenie: jeśli aktywność, usługa lub odbiornik w aplikacji używa filtrów intencji i nie ma jawnie ustawionej wartości dla android:exported
, aplikacja nie może zostać zainstalowana na urządzeniu z Androidem 12 lub nowszym.
W elementach <intent-filter>
możesz określić typy intencji do zaakceptowania, używając co najmniej jednego z tych trzech elementów:
<action>
- W atrybucie
name
deklaruje przyjęte działanie intencji. Wartość musi być literałem w postaci ciągu działania, a nie stałą klasy. <data>
- Określa typ akceptowanych danych za pomocą co najmniej jednego atrybutu, który określa różne aspekty identyfikatora URI danych (
scheme
,host
,port
,path
) i typ MIME. <category>
- Określa kategorię intencji zaakceptowaną w atrybucie
name
. Wartość musi być literacką wartością ciągu znaków działania, a nie stałą klasy.Uwaga: aby otrzymywać niejawne intencje, musisz uwzględnić kategorię
CATEGORY_DEFAULT
w filtrze intencji. MetodystartActivity()
istartActivityForResult()
traktują wszystkie intencje tak, jakby były zadeklarowane w kategoriiCATEGORY_DEFAULT
. Jeśli nie zadeklarujesz tej kategorii w filtrze intencji, żadne intencje niejawne nie trafią do Twojej aktywności.
Oto na przykład deklaracja aktywności z filtrem intencji, która ma odbierać intencję ACTION_SEND
, gdy typ danych to tekst:
<activity android:name="ShareActivity" android:exported="false"> <intent-filter> <action android:name="android.intent.action.SEND"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="text/plain"/> </intent-filter> </activity>
Możesz utworzyć filtr obejmujący więcej niż 1 wystąpienie <action>
, <data>
lub <category>
.
Jeśli tak, musisz mieć pewność, że komponent może obsłużyć wszystkie kombinacje tych elementów filtra.
Jeśli chcesz obsługiwać wiele rodzajów intencji, ale tylko w określonych kombinacjach działań, danych i typów kategorii, musisz utworzyć kilka filtrów intencji.
Ukryta intencja jest testowana za pomocą filtra przez porównanie intencji z każdym z tych trzech elementów. Aby intencja mogła zostać dostarczona do komponentu, musi przejść wszystkie 3 testy. Jeśli nie uda się dopasować nawet jednego z nich, system Android nie przekaże intencji do danego komponentu. Składnik może jednak mieć wiele filtrów intencji, więc intencja, która nie przejdzie przez jeden z nich, może zostać przepuszczona przez inny. Więcej informacji o tym, jak system rozpoznaje intencje, znajdziesz w sekcji dotyczącej rozwiązywania intencji poniżej.
Uwaga: użycie filtra intencji nie jest bezpiecznym sposobem na uniemożliwienie uruchamiania Twoich komponentów przez inne aplikacje. Chociaż filtry intencji ograniczają działanie komponentu tylko do określonych rodzajów domniemanych intencji, inna aplikacja może uruchomić komponent Twojej aplikacji, używając do tego wyraźnej intencji, jeśli deweloper określił nazwy komponentów.
Jeśli zależy Ci na tym, aby tylko Twoja aplikacja mogła uruchamiać jeden ze swoich komponentów, nie deklaruj w manifeście żadnych filtrów intencji. Zamiast tego ustaw atrybut exported
na "false"
dla tego komponentu.
Aby uniknąć przypadkowego uruchomienia Service
innej aplikacji, zawsze używaj wyraźnego zamiaru do uruchamiania własnej usługi.
Uwaga:
w przypadku wszystkich działań musisz zadeklarować filtry intencji w pliku manifestu.
Filtry dla odbiorników transmisji mogą być jednak rejestrowane dynamicznie przez wywołanie funkcji registerReceiver()
. Następnie możesz wyrejestrować odbiornik w usłudze unregisterReceiver()
. Dzięki temu aplikacja może odbierać określone transmisje tylko przez określony czas, gdy jest uruchomiona.
Przykładowe filtry
Aby zademonstrować niektóre działanie filtra intencji, przygotowaliśmy przykład z pliku manifestu aplikacji do udostępniania treści w mediach społecznościowych:
<activity android:name="MainActivity" android:exported="true"> <!-- This activity is the main entry, should appear in app launcher --> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name="ShareActivity" android:exported="false"> <!-- This activity handles "SEND" actions with text data --> <intent-filter> <action android:name="android.intent.action.SEND"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="text/plain"/> </intent-filter> <!-- This activity also handles "SEND" and "SEND_MULTIPLE" with media data --> <intent-filter> <action android:name="android.intent.action.SEND"/> <action android:name="android.intent.action.SEND_MULTIPLE"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="application/vnd.google.panorama360+jpg"/> <data android:mimeType="image/*"/> <data android:mimeType="video/*"/> </intent-filter> </activity>
Pierwsza aktywność, MainActivity
, to główny punkt wejścia do aplikacji – aktywność, która otwiera się, gdy użytkownik uruchamia aplikację za pomocą ikony menu:
- Działanie
ACTION_MAIN
wskazuje, że jest to główny punkt wejścia i że nie są wymagane żadne dane o intencji. - Kategoria
CATEGORY_LAUNCHER
wskazuje, że ikona tej aktywności powinna znajdować się w Menu z aplikacjami systemu. Jeśli element<activity>
nie określa ikony za pomocą atrybutuicon
, system używa ikony z elementu<application>
.
Aby aktywność była widoczna w Menu z aplikacjami, te 2 elementy muszą być sparowane.
Druga aktywność, ShareActivity
, ma ułatwiać udostępnianie tekstu i multimediów. Użytkownicy mogą przejść do tej czynności z poziomu MainActivity
, ale mogą też otworzyć ShareActivity
bezpośrednio z innej aplikacji, która wysyła ukrytą intencję pasującą do jednego z 2 filtrów intencji.
Uwaga: typ MIME application/vnd.google.panorama360+jpg
to specjalny typ danych, który określa zdjęcia panoramiczne. Możesz je obsługiwać za pomocą interfejsów API Google Panorama.
dopasowywać intencje do filtrów intencji innych aplikacji;
Jeśli inna aplikacja jest kierowana na Androida 13 (poziom interfejsu API 33) lub nowszego, może obsłużyć intencję Twojej aplikacji tylko wtedy, gdy Twoja intencja pasuje do działań i kategorii elementu <intent-filter>
w tej innej aplikacji. Jeśli system nie znajdzie dopasowania, rzuci błąd ActivityNotFoundException
.
Aplikacja wysyłająca musi obsłużyć tę sytuację.
Jeśli zaktualizujesz aplikację, aby była kierowana na Androida 13 lub nowszego, wszystkie intencje pochodzące z aplikacji zewnętrznych są dostarczane do wyeksportowanego komponentu aplikacji tylko wtedy, gdy intencje te pasują do działań i kategorii elementu <intent-filter>
zadeklarowanego przez aplikację. Takie zachowanie występuje niezależnie od docelowej wersji pakietu SDK aplikacji wysyłającej.
W tych przypadkach dopasowywanie intencji nie jest egzekwowane:
- Intencje dostarczane do komponentów, które nie deklarują żadnych filtrów intencji.
- Intencje pochodzące z tej samej aplikacji.
- Intencje pochodzące z systemu, czyli intencje wysyłane z identyfikatora „system UID” (uid=1000). Aplikacje systemowe to
system_server
oraz aplikacje, które ustawiają wartośćandroid:sharedUserId
naandroid.uid.system
. - Intencje pochodzące z roota.
Dowiedz się więcej o dopasowywaniu intencji.
Korzystanie z oczekującej intencji
Obiekt PendingIntent
to otoka wokół obiektu Intent
. Głównym celem PendingIntent
jest udzielenie aplikacji zewnętrznej uprawnień do używania zawartego w niej Intent
tak, jakby była ona wykonywana w ramach procesu aplikacji.
Główne przypadki użycia intencji oczekującej to:
- Zadeklarowanie zamiaru, który ma być wykonany, gdy użytkownik wykona działanie związane z Twoim powiadomieniem (
NotificationManager
systemu Androida wykonujeIntent
). - Deklarowanie intencji do wykonania, gdy użytkownik wykona działanie za pomocą widżetu aplikacji (aplikacja na ekranie głównym wykonuje działanie
Intent
). - Oświadczenie o intencji do wykonania w określonym czasie w przyszłości (
AlarmManager
systemu Androida wykonujeIntent
).
Obiekt Intent
jest przeznaczony do obsługi przez określony typ komponentu aplikacji (Activity
, Service
lub BroadcastReceiver
), tak samo jak obiekt PendingIntent
należy utworzyć z tą samą zasadą. Gdy używasz intencji oczekującej, aplikacja nie wykonuje intencji za pomocą wywołania takiego jak startActivity()
. Zamiast tego musisz zadeklarować odpowiedni typ komponentu podczas tworzenia elementu PendingIntent
, wywołując odpowiednią metodę kreatora:
PendingIntent.getActivity()
dla zasobuIntent
, którego nazwa zaczyna się odActivity
.PendingIntent.getService()
dlaIntent
, który rozpoczynaService
.PendingIntent.getBroadcast()
dlaIntent
, który rozpoczynaBroadcastReceiver
.
O ile Twoja aplikacja nie otrzymuje oczekujących intencji z innych aplikacji, powyższe metody tworzenia PendingIntent
będą prawdopodobnie jedynymiPendingIntent
metodami, których kiedykolwiek będziesz potrzebować.
Każda metoda przyjmuje bieżącą aplikację Context
, Intent
, którą chcesz opakować, oraz co najmniej 1 flagę, która określa sposób użycia intencji (np. czy można jej użyć więcej niż raz).
Więcej informacji o używaniu oczekujących intencji znajdziesz w dokumentacji dotyczącej poszczególnych przypadków użycia, na przykład w przewodnikach po interfejsach API powiadomień i widżetów aplikacji.
Określ mutowalność
Jeśli aplikacja jest kierowana na Androida 12 lub nowszego, musisz określić zmienność każdego obiektu PendingIntent
tworzonego przez aplikację. Aby zadeklarować, że dany obiekt PendingIntent
jest zmienny lub niezmienny, użyj odpowiednio flagi PendingIntent.FLAG_MUTABLE
lub PendingIntent.FLAG_IMMUTABLE
.
Jeśli aplikacja próbuje utworzyć obiekt PendingIntent
bez ustawienia żadnej flagi zmienności, system zgłasza błąd IllegalArgumentException
, a w Logcat pojawia się ten komunikat:
PACKAGE_NAME: Targeting S+ (version 31 and above) requires that one of \
FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if \
some functionality depends on the PendingIntent being mutable, e.g. if \
it needs to be used with inline replies or bubbles.
Gdy tylko jest to możliwe, twórz stałe intencje oczekujące
W większości przypadków aplikacja powinna tworzyć niezmienne obiekty PendingIntent
, jak pokazano w tym fragmencie kodu. Jeśli obiekt PendingIntent
jest stały, inne aplikacje nie mogą modyfikować intencji, aby dostosować wynik wywołania intencji.
Kotlin
val pendingIntent = PendingIntent.getActivity(applicationContext, REQUEST_CODE, intent, /* flags */ PendingIntent.FLAG_IMMUTABLE)
Java
PendingIntent pendingIntent = PendingIntent.getActivity(getApplicationContext(), REQUEST_CODE, intent, /* flags */ PendingIntent.FLAG_IMMUTABLE);
W niektórych przypadkach wymagane są jednak obiekty PendingIntent
, które można zmieniać:
- Obsługa działań bezpośrednich w powiadomieniach. Odpowiedź bezpośrednia wymaga zmiany danych klipu w obiekcie PendingIntent powiązanym z odpowiedzią. Aby żądanie tej zmiany było zwykle możliwe, należy przekazać
FILL_IN_CLIP_DATA
jako flagę do metodyfillIn()
. - Powiązanie powiadomień z ramami Androida Auto za pomocą instancji
CarAppExtender
. - umieszczanie rozmów w dymkach za pomocą instancji
PendingIntent
. Zmienny obiektPendingIntent
pozwala systemowi stosować odpowiednie flagi, takie jakFLAG_ACTIVITY_MULTIPLE_TASK
iFLAG_ACTIVITY_NEW_DOCUMENT
. - Wysyłanie żądania informacji o lokalizacji urządzenia przez wywołanie interfejsu
requestLocationUpdates()
lub podobnego. Zmienne obiektyPendingIntent
pozwalają systemowi dodawać dodatki, które reprezentują zdarzenia cyklu życia lokalizacji. Te zdarzenia obejmują zmianę lokalizacji i usługodawcy. - ustawianie alarmów za pomocą
AlarmManager
. Zmienny obiektPendingIntent
umożliwia systemowi dodanie dodatkowej intencjiEXTRA_ALARM_COUNT
. Ten element reprezentuje liczbę powtórzeń alarmu. Dzięki temu intencja może dokładnie poinformować aplikację, czy powtarzający się alarm był włączany wielokrotnie, na przykład wtedy, gdy urządzenie było w stanie uśpienia.
Jeśli Twoja aplikacja tworzy zmienny obiekt PendingIntent
, zdecydowanie zalecamy użycie wyraźnego zamiaru i wypełnienie pola ComponentName
. Dzięki temu za każdym razem, gdy inna aplikacja wywoła PendingIntent
i przekaże kontrolę Twojej aplikacji, zawsze uruchamia się ten sam komponent w Twojej aplikacji.
Używanie intencji bezpośrednich w intencjach oczekujących
Aby lepiej zdefiniować, jak inne aplikacje mogą korzystać z oczekujących intencji, zawsze otocz intencję oczekującą na intencję jawną. Aby zastosować tę sprawdzoną metodę, wykonaj te czynności:
- Sprawdź, czy działanie, pakiet i pola komponentu podstawowej intencji są ustawione.
-
Użyj narzędzia
FLAG_IMMUTABLE
dodanego w Androidzie 6.0 (poziom interfejsu API 23), aby utworzyć intencje oczekujące. Ten parametr uniemożliwia aplikacjom, które otrzymują intencjęPendingIntent
, wypełnianie brakujących właściwości. JeśliminSdkVersion
Twojej aplikacji jest22
lub mniejszy, możesz zapewnić bezpieczeństwo i zgodność, używając tego kodu:if (Build.VERSION.SDK_INT >= 23) { // Create a PendingIntent using FLAG_IMMUTABLE. } else { // Existing code that creates a PendingIntent. }
Rozwiązanie intencji
Gdy system otrzyma domyślną intencję rozpoczęcia aktywności, wyszuka najlepszą aktywność dla tej intencji, porównując ją z filtrami intencji pod 3 względami:
- Działanie.
- Dane (zarówno identyfikator URI, jak i typ danych).
- Category [Kategoria]:
W następnych sekcjach opisujemy, jak intencje są dopasowywane do odpowiednich komponentów zgodnie z deklaracją filtra intencji w pliku manifestu aplikacji.
Test działania
Aby określić akceptowane działania związane z zamiarem, filtr zamiaru może zawierać 0 lub więcej elementów <action>
, jak w tym przykładzie:
<intent-filter> <action android:name="android.intent.action.EDIT" /> <action android:name="android.intent.action.VIEW" /> ... </intent-filter>
Aby ten filtr zadziałał, działanie określone w parametrze Intent
musi być zgodne z jednym z działań wymienionych w filtrze.
Jeśli filtr nie zawiera żadnych działań, nie ma żadnej intencji, która mogłaby zostać dopasowana, więc wszystkie intencje kończą się niepowodzeniem. Jeśli jednak Intent
nie określa działania, test kończy test, o ile filtr zawiera co najmniej 1 działanie.
Testowanie kategorii
Aby określić akceptowane kategorie intencji, filtr intencji może zawierać 0 lub więcej elementów <category>
, jak w tym przykładzie:
<intent-filter> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> ... </intent-filter>
Aby intencja przeszła test kategorii, każda kategoria w Intent
musi być zgodna z kategorią w filtrze. Odwrotna zależność nie jest konieczna – filtr intencji może deklarować więcej kategorii niż określono w Intent
, a Intent
nadal jest akceptowany. Dlatego intencja bez kategorii zawsze przechodzi ten test, niezależnie od tego, jakie kategorie są zadeklarowane w filtrze.
Uwaga: Android automatycznie stosuje kategorię CATEGORY_DEFAULT
do wszystkich domyślnych intencji przekazywanych do startActivity()
i startActivityForResult()
.
Jeśli chcesz, aby Twoja aktywność odbierała niejawne intencje, musisz uwzględnić w jej filtrach intencji kategorię "android.intent.category.DEFAULT"
, jak pokazano w poprzednim przykładzie <intent-filter>
.
Test danych
Aby określić akceptowane dane o zamiarze, filtr zamiaru może zawierać 0 lub więcej elementów <data>
, jak w tym przykładzie:
<intent-filter> <data android:mimeType="video/mpeg" android:scheme="http" ... /> <data android:mimeType="audio/mpeg" android:scheme="http" ... /> ... </intent-filter>
Każdy element <data>
może określać strukturę identyfikatora URI oraz typ danych (typ multimediów MIME).
Każda część identyfikatora URI jest osobnym atrybutem: scheme
, host
, port
i path
:
<scheme>://<host>:<port>/<path>
Przykład poniżej pokazuje możliwe wartości tych atrybutów:
content://com.example.project:200/folder/subfolder/etc
W tym identyfikatorze URI schemat to content
, host to com.example.project
, port to 200
, a ścieżka to folder/subfolder/etc
.
Każdy z tych atrybutów jest opcjonalny w elemencie <data>
, ale występują zależności liniowe:
- Jeśli nie określisz schematu, host zostanie zignorowany.
- Jeśli nie podasz hosta, port będzie ignorowany.
- Jeśli nie określisz ani schematu, ani hosta, ścieżka zostanie zignorowana.
Podczas porównywania identyfikatora URI w intencji ze specyfikacją identyfikatora URI w filtrze porównywane są tylko te części identyfikatora URI, które są uwzględnione w filtrze. Na przykład:
- Jeśli filtr określa tylko schemat, wszystkie identyfikatory URI z tym schematem pasują do filtra.
- Jeśli filtr określa schemat i autorytet, ale nie ścieżkę, wszystkie URI z tym samym schematem i autorytetem przechodzą przez filtr niezależnie od ścieżki.
- Jeśli filtr określa schemat, autorytet i ścieżkę, tylko URI z tymi samymi wartościami przechodzą przez filtr.
Uwaga: specyfikacja ścieżki może zawierać symbol wieloznaczny gwiazdka (*), aby wymagać tylko częściowego dopasowania nazwy ścieżki.
Test danych porównuje identyfikator URI i typ MIME w intencji z identyfikatorem URI i typem MIME określonym w filtrze. Oto zasady:
- Intencja, która nie zawiera ani identyfikatora URI, ani typu MIME, zalicza test tylko wtedy, gdy filtr nie określa żadnych identyfikatorów URI ani typów MIME.
- Intencja, która zawiera identyfikator URI, ale nie zawiera typu MIME (ani jawnego, ani niewywnioskowanego na podstawie identyfikatora URI), kończy test tylko wtedy, gdy identyfikator URI pasuje do formatu URI filtra, a filtr nie określa typu MIME.
- Intencje zawierające typ MIME, ale nie URI, przechodzą test tylko wtedy, gdy filtr zawiera ten sam typ MIME i nie określa formatu URI.
- Intencja, która zawiera zarówno identyfikator URI, jak i typ MIME (jawny lub możliwy do wywnioskowania z identyfikatora URI), przekazuje część MIME związaną z typem MIME w teście tylko wtedy, gdy ten typ pasuje do typu wymienionego w filtrze. Przekazuje część URI testu, jeśli jego identyfikator URI pasuje do identyfikatora URI w filtrze albo gdy zawiera identyfikator URI
content:
lubfile:
, a filtr go nie określa. Inaczej mówiąc, komponent jest uznawany za obsługujący danecontent:
ifile:
, jeśli jego filtr zawiera tylko typ MIME.
Uwaga: jeśli intencja określa typ URI lub MIME, test danych zakończy się niepowodzeniem, jeśli w elementach <intent-filter>
nie ma elementów <data>
.
Ostatnia reguła (d) odpowiada oczekiwaniu,
że komponenty mogą pobierać dane lokalne od pliku lub dostawcy treści.
Dlatego filtry mogą uwzględniać tylko typ danych i nie muszą nadawać schematom content:
i file:
jawnym nazwom.
Ten przykład pokazuje typowy przypadek, w którym element <data>
informuje Androida, że komponent może pobierać dane obrazu od dostawcy treści i je wyświetlać:
<intent-filter> <data android:mimeType="image/*" /> ... </intent-filter>
Najczęściej stosuje się filtry, które określają typ danych, ale nie identyfikator URI, ponieważ większość dostępnych danych jest rozpowszechniana przez dostawców treści.
Inną typową konfiguracją jest filtr ze schematem i typem danych. Na przykład element <data>
, taki jak ten, informuje Androida, że komponent może pobierać dane wideo z sieci, aby wykonać działanie:
<intent-filter> <data android:scheme="http" android:mimeType="video/*" /> ... </intent-filter>
Dopasowywanie intencji
Intencje są dopasowywane do filtrów intencji nie tylko po to, aby wykryć docelowy komponent do aktywacji, ale też po to, aby dowiedzieć się czegoś o zbiorze komponentów na urządzeniu. Na przykład aplikacja Home wypełnia menu uruchamiania aplikacji, wyszukując wszystkie aktywności z filtrami intencji, które określają ACTION_MAIN
działanie i CATEGORY_LAUNCHER
kategorię.
Dopasowanie następuje tylko wtedy, gdy działania i kategorie w intencji pasują do filtra, zgodnie z opisem w dokumentacji klasy IntentFilter
.
Aplikacja może używać dopasowania intencji w sposób podobny do aplikacji Home.
Obiekt PackageManager
zawiera zestaw metod query...()
, które zwracają wszystkie komponenty, które mogą odpowiadać na dany zamiar, oraz podobną serię metod resolve...()
, które określają najlepszy komponent do odpowiedzi na zamiar. Na przykład:
queryIntentActivities()
zwraca listę wszystkich działań, które mogą wykonać
intencję przekazaną jako argument, a queryIntentServices()
zwraca podobną listę usług.
Żadna z tych metod nie aktywuje komponentów, tylko wyświetla te, które mogą odpowiadać. W przypadku odbiorników jest podobna metoda,queryBroadcastReceivers()
.