- składnia:
-
<uri-relative-filter-group android:allow=["true" | "false"]> <data ... /> ... </uri-relative-filter-group>
- zawarte w:
-
<intent-filter> - może zawierać:
-
<data> - description:
- Tworzy precyzyjne reguły dopasowywania
Intent, które mogą obejmować parametry zapytania i fragmenty identyfikatora URI. W zależności od atrybutuandroid:allowreguły mogą być regułami uwzględniającymi (zezwalanie) lub regułami wykluczającymi (blokowanie). Reguły dopasowywania są określane przez atrybutypath*,fragment*iquery*zawartych elementów<data>.Dopasowywanie
Aby dopasować identyfikator URI, każdy fragment grupy filtrów względnych identyfikatorów URI musi odpowiadać części identyfikatora URI. W grupie filtrów względnych adresów URI mogą występować fragmenty adresów URI, które nie są określone w grupie. Przykład:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:query="param1=value1" /> <data android:query="param2=value2" /> </uri-relative-filter-group> ... </intent-filter>
Filtr pasuje do:
https://project.example.com/any/path/here?param1=value1¶m2=value2¶m3=value3ponieważ wszystko określone przez grupę filtrów względnych URI jest obecne. Filtr pasuje też do wartościhttps://project.example.com/any/path/here?param2=value2¶m1=value1, ponieważ kolejność parametrów zapytania nie ma znaczenia. Filtr nie pasuje jednak do kolumnyhttps://project.example.com/any/path/here?param1=value1, w której brakuje kolumnyparam2=value2.LUB i I
Tagi
<data>spoza bloku<uri-relative-filter-group>są łączone za pomocą operatora LUB, a tagi<data>wewnątrz bloku<uri-relative-filter-group>są łączone za pomocą operatora I.Rozważ ten przykład:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <data android:pathPrefix="/prefix" /> <data android:pathSuffix="suffix" /> ... </intent-filter>
Filtr pasuje do ścieżek, które zaczynają się od
/prefixLUB kończą się nasuffix.Natomiast w następującym przykładzie pasują ścieżki, które zaczynają się od
/prefixi kończą nasuffix:<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group> <data android:pathPrefix="/prefix" /> <data android:pathSuffix="suffix" /> </uri-relative-filter-group> ... </intent-filter>
W rezultacie wiele atrybutów
pathw tym samym polu<uri-relative-filter-group>nie pasuje do niczego:<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group> <data android:path="/path1" /> <data android:path="/path2" /> </uri-relative-filter-group> ... </intent-filter>
Kolejność deklaracji
Rozważ ten przykład:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group> <data android:fragment="fragment" /> </uri-relative-filter-group> <uri-relative-filter-group android:allow="false"> <data android:fragmentPrefix="fragment" /> </uri-relative-filter-group> ... </intent-filter>
Filtr pasuje do fragmentu
#fragment, ponieważ dopasowanie jest znajdowane przed zweryfikowaniem reguły wykluczenia, ale fragmenty takie jak#fragment123nie pasują.Tagi pokrewne
Tagi
<uri-relative-filter-group>współdziałają z tagami<data>(czyli tagami<data>, które znajdują się poza tagiem<uri-relative-filter-group>, ale w tym samym<intent-filter>). Aby działały prawidłowo, tagi<uri-relative-filter-group>muszą mieć tagi<data>, ponieważ atrybuty URI są na poziomie<intent-filter>wzajemnie zależne:- Jeśli w przypadku filtra intencji nie zostanie określony parametr
scheme, wszystkie pozostałe atrybuty URI zostaną zignorowane. - Jeśli filtr nie ma określonego atrybutu
host, atrybutporti wszystkie atrybutypath*są ignorowane.
<data>podrzędne<intent-filter>są oceniane przed tagami<uri-relative-filter-group>. Następnie tagi<uri-relative-filter-group>są oceniane po kolei, na przykład:<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="false"> <data android:path="/path" /> <data android:query="query" /> </uri-relative-filter-group> <data android:path="/path" /> ... </intent-filter>
Filtr akceptuje
https://project.example.com/path?query, ponieważ pasuje do<data android:path="/path" />, które nie jest objęte regułą wykluczenia<uri-relative-filter-group>.Częsty przypadek użycia
Załóżmy, że masz identyfikator URI
https://project.example.com/path, który chcesz dopasować do identyfikatoraIntentw zależności od obecności lub wartości parametru zapytania. Aby utworzyć filtr intencji, który pasuje do wyrażeniahttps://project.example.com/pathi blokuje wyrażeniehttps://project.example.com/path?query, możesz spróbować użyć tego wyrażenia:<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:path="/path" /> </uri-relative-filter-group> ... </intent-filter>
To w ogóle nie działa. Identyfikator URI
https://project.example.com/path?querydopasowuje się do ścieżki/path, a tag<uri-relative-filter-group>pozwala uwzględnić dodatkowe części podczas dopasowywania.Zmień filtr zamiaru w ten sposób:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="false"> <data android:path="/path" /> <data android:queryAdvancedPattern=".+" /> </uri-relative-filter-group> <uri-relative-filter-group android:allow="true"> <data android:path="/path" /> </uri-relative-filter-group> ... </intent-filter>
Ten filtr działa, ponieważ reguły blokowania, które zabraniają stosowania pustych parametrów zapytań, są sprawdzane jako pierwsze.
Aby uprościć kod, odwróć zachowanie, aby zezwolić na parametry zapytania i blokować identyfikatory URI bez parametrów zapytania:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:path="/path" /> <data android:queryAdvancedPattern=".+" /> </uri-relative-filter-group> ... </intent-filter>
Znaki zakodowane w identyfikatorze URI
Aby dopasować identyfikatory URI zawierające znaki zakodowane w identyfikatorze URI, w filtrze wpisz nieprzetworzone, niekodowane znaki, np.:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:query="param=value!" /> </uri-relative-filter-group> ... </intent-filter>
Filtr pasuje do
?param=value!i?param=value%21.Jeśli jednak w filtrze wpiszesz zakodowane znaki w ten sposób:
<intent-filter...> <data android:scheme="https" android:host="project.example.com" /> <uri-relative-filter-group android:allow="true"> <data android:query="param=value%21" /> </uri-relative-filter-group> ... </intent-filter>
Filtr nie pasuje ani do
?param=value!, ani do?param=value%21.Liczba elementów
W elemencie
<intent-filter>możesz umieścić dowolną liczbę elementów<uri-relative-filter-group>.Dodatkowe zasoby
Informacje o działaniu filtrów intencji, w tym reguły dopasowywania obiektów intencji do filtrów, znajdziesz w artykułach Intencje i filtry intencji i Filtry intencji.
Informacje o
<uri-relative-filter-group>znajdziesz w artykułachUriRelativeFilterGroupiUriRelativeFilter. - Jeśli w przypadku filtra intencji nie zostanie określony parametr
- atrybuty:
-
android:allow- Czy ta grupa filtrów względem URI jest regułą uwzględniania (zezwalania), a nie regułą wykluczania (blokowania). Wartością domyślną jest
"true".Wartość Opis "true"(domyślnie)Jeśli grupa filtrów względnych identyfikatora URI pasuje, filtr intencji pasuje "false"Jeśli grupa filtrów względnych adresów URI pasuje, filtr intencji nie pasuje
- wprowadzona w:
- Poziom API 35
- Zobacz też:
-
<intent-filter><data>
<uri-relative-filter-group>
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[null,null,["Ostatnia aktualizacja: 2025-07-27 UTC."],[],[]]