Hay mucha desinformación sobre este tema, sobre todo de la propia documentación de Google. Lo mejor, y dada la extraña lógica, posiblemente la única documentación real sea el código fuente.
La implementación del filtro de intención tiene una lógica que casi desafía la descripción. El código del analizador es la otra pieza relevante del rompecabezas.
Los siguientes filtros se acercan bastante al comportamiento sensato. Los patrones de ruta se aplican para las intenciones de esquema de "archivo".
La coincidencia de patrón de tipo de mimo global coincidirá con todos los tipos siempre que la extensión del archivo coincida. Esto no es perfecto, pero es la única forma de coincidir con el comportamiento de administradores de archivos como ES File Explorer, y se limita a las intenciones en las que coincide la extensión de archivo / URI.
No he incluido otros esquemas como "http" aquí, pero probablemente funcionarán bien en todos estos filtros.
El esquema extraño es "contenido", para el cual la extensión no está disponible para el filtro. Pero siempre que el proveedor indique su tipo de MIME (por ejemplo, Gmail transmitirá el tipo de MIME para el archivo adjunto sin obstáculos), el filtro coincidirá.
Puntos a tener en cuenta:
- Tenga en cuenta que nada se comporta de manera consistente en los filtros, es un laberinto de casos específicos y trata la violación del principio de mínima sorpresa como un objetivo de diseño. Ninguno de los algoritmos de coincidencia de patrones sigue la misma sintaxis o comportamiento. La ausencia de un campo a veces es un comodín y otras no lo es. Los atributos dentro de un elemento de datos a veces deben ir juntos y a veces ignorar la agrupación. Realmente podría haberse hecho mejor.
- El esquema Y el host deben especificarse para que las reglas de ruta coincidan (al contrario de la guía API de Google, actualmente).
- Al menos ES File Explorer genera intents con un tipo MIME de "", que se filtra de manera muy diferente a nulo, es imposible de hacer coincidir explícitamente y solo puede coincidir con el arriesgado filtro "* / *".
- El filtro "* / *" NO coincidirá con Intents con un tipo de MIME nulo, que requiere un filtro separado para este caso específico sin ningún tipo de MIME.
- El esquema de "contenido" solo puede coincidir con el tipo MIME, porque el nombre del archivo original no está disponible en la intención (al menos con Gmail).
- La agrupación de atributos en elementos de "datos" separados es (casi) irrelevante para la interpretación, con la excepción específica del host y el puerto, que se emparejan. Todo lo demás no tiene una asociación específica dentro de un elemento de "datos" o entre elementos de "datos".
Con todo esto en mente, aquí hay un ejemplo con comentarios:
<!--
Capture content by MIME type, which is how Gmail broadcasts
attachment open requests. pathPattern and file extensions
are ignored, so the MIME type *MUST* be explicit, otherwise
we will match absolutely every file opened.
-->
<intent-filter
android:icon="@drawable/icon"
android:label="@string/app_name"
android:priority="50" >
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="file" />
<data android:scheme="content" />
<data android:mimeType="application/vnd.my-type" />
</intent-filter>
<!--
Capture file open requests (pathPattern is honoured) where no
MIME type is provided in the Intent. An Intent with a null
MIME type will never be matched by a filter with a set MIME
type, so we need a second intent-filter if we wish to also
match files with this extension and a non-null MIME type
(even if it is non-null but zero length).
-->
<intent-filter
android:icon="@drawable/icon"
android:label="@string/app_name"
android:priority="50" >
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="file" />
<data android:host="*" />
<!--
Work around Android's ugly primitive PatternMatcher
implementation that can't cope with finding a . early in
the path unless it's explicitly matched.
-->
<data android:pathPattern=".*\\.my-ext" />
<data android:pathPattern=".*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\..*\\..*\\.my-ext" />
</intent-filter>
<!--
Capture file open requests (pathPattern is honoured) where a
(possibly blank) MIME type is provided in the Intent. This
filter may only be necessary for supporting ES File Explorer,
which has the probably buggy behaviour of using an Intent
with a MIME type that is set but zero-length. It's
impossible to match such a type except by using a global
wildcard.
-->
<intent-filter
android:icon="@drawable/icon"
android:label="@string/app_name"
android:priority="50" >
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="file" />
<data android:host="*" />
<data android:mimeType="*/*" />
<!--
Work around Android's ugly primitive PatternMatcher
implementation that can't cope with finding a . early in
the path unless it's explicitly matched.
-->
<data android:pathPattern=".*\\.my-ext" />
<data android:pathPattern=".*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\..*\\.my-ext" />
<data android:pathPattern=".*\\..*\\..*\\..*\\..*\\..*\\..*\\.my-ext" />
</intent-filter>