Rechazo en Google Play
Google solo permite el acceso amplio a fotos y vídeos a las apps cuyo propósito principal necesita toda la biblioteca multimedia, como las apps de galería. Una app web que permite a los usuarios subir una foto de perfil o un recibo no cumple los requisitos, y tampoco le hace falta: el selector del sistema entrega el archivo elegido a tu WebView sin ningún permiso multimedia. Quita los permisos de todos los canales y vuelve a enviarla.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
Desde Android 13, el acceso amplio a las imágenes y los vídeos de un usuario se divide en dos permisos, READ_MEDIA_IMAGES y READ_MEDIA_VIDEO. Google Play trata ambos como restringidos: una app solo puede solicitarlos si un selector del sistema, como el selector de fotos de Android, no puede cubrir su funcionalidad principal. De las apps que solo necesitan archivos multimedia una vez o de forma ocasional (una foto de perfil, un recibo, una foto adjunta a una incidencia de soporte o a un anuncio) se espera que usen el selector y quiten los permisos de su manifiesto. Las apps que los conservan deben explicar el motivo en una declaración en la Play Console.
Los detalles de la política de Google citan las apps tipo galería, que gestionan todos los archivos multimedia de un usuario, como el caso típico de acceso amplio. El cumplimiento total es obligatorio desde 2025; a las apps que no cumplen se les pueden bloquear las actualizaciones o se pueden retirar. Además, el selector ofrece una experiencia mejor: los usuarios eligen exactamente qué imágenes compartir en lugar de abrir toda su biblioteca a tu app.
Normalmente los desarrolladores ven una incidencia de la política de permisos de fotos y vídeos que indica que el uso del permiso no está directamente relacionado con el propósito principal de la app, porque la app solo necesita acceso puntual o poco frecuente a archivos multimedia. El aviso te pide que quites READ_MEDIA_IMAGES y READ_MEDIA_VIDEO de todos los version codes del envío, tanto en producción como en los canales de prueba, o que envíes una declaración si tu funcionalidad principal necesita de verdad un acceso amplio. En una app web, reformular la declaración rara vez ayuda. Quitar el permiso, sí.
Cuando tu app web muestra <input type="file" accept="image/*">, el WebView de Android le pide a la app nativa que abra un selector de archivos. WebViewGold responde con la cámara, la galería o ambas, según el valor de filePickerMode en Config.java: 0 para cámara y galería, 1 solo para cámara, 2 solo para galería. El archivo que elige el usuario se devuelve a la página y se sube igual que en la web.
Elegir un archivo a través de un selector del sistema concede a la app acceso solo a ese archivo, mediante el propio toque del usuario. Por eso un flujo de subida normal no necesita READ_MEDIA_IMAGES. Hacer una foto nueva es una función de cámara que usa el permiso de cámara (requireCamera), un tema aparte que trata la guía de permisos. El escáner de documentos se integra en el mismo selector y devuelve un PDF de la misma manera.
¡Una forma estupenda de convertir tu web app en una app nativa! Entrega rápida y una manera genial de llevar tus apps a las tiendas sin tener que desarrollar una app nativa completa.
| Función en tu app web | Permiso necesario | Ajuste de WebViewGold |
|---|---|---|
| Subir una foto o un archivo existente | Ningún permiso multimedia; el selector comparte el archivo elegido | filePickerMode 0 o 2 |
| Hacer una foto nueva para subirla | Cámara | requireCamera true, filePickerMode 0 o 1 |
| Escanear un código QR o de barras | Cámara | requireCamera; consulta la documentación del escáner QR |
Guardar una imagen en la galería (savethisimage://) | En las versiones actuales de Android no hace falta acceso de lectura a la biblioteca para añadir una imagen nueva | requireStorage para descargas y subidas; consulta la documentación del gestor de descargas |
| Mostrar toda la biblioteca de fotos del usuario dentro de tu app | READ_MEDIA_IMAGES y READ_MEDIA_VIDEO más una declaración | Rara vez encaja en una app web; un gestor de galería es una app nativa |
Unos treinta minutos en Android Studio, más una ronda de pruebas en un teléfono.
En la Play Console, abre el App bundle explorer (Explorador de app bundles) de la versión rechazada y mira su lista de permisos. En Android Studio, abre AndroidManifest.xml y cambia a la pestaña Merged Manifest; ahí ves si una entrada viene de tu propio manifiesto o de una biblioteca.
Pon filePickerMode en lo que necesite tu subida, pon requireCamera en false si ninguna función hace fotos ni escanea códigos, y deja requireStorage en true solo si la app sube o descarga archivos, como describe la referencia de Config.java.
Borra las líneas READ_MEDIA_IMAGES y READ_MEDIA_VIDEO de tu manifiesto, o añade las reglas de eliminación de abajo si las aporta una biblioteca. Si aparece también READ_MEDIA_VISUAL_USER_SELECTED, quítalo junto con ellas, salvo que sepas exactamente por qué está ahí.
Instala la nueva compilación desde las pruebas internas en un dispositivo con Android 14 o posterior y prueba una subida desde la galería, una foto hecha con la cámara, el escáner de documentos si lo usas, una imagen guardada con savethisimage:// y la descarga de un PDF. Si algo falla, envía al soporte de WebViewGold la versión de tu plantilla y el flujo que falla antes de hacer el envío.
Sube el bundle nuevo con un version code más alto y sustituye también los bundles antiguos en los canales de pruebas internas, cerradas y abiertas. Google revisa todos los version codes del envío.
Si la Play Console sigue mostrando la declaración de permisos de fotos y vídeos, indica que la app ya no solicita estos permisos y después envía los cambios a revisión.
Úsalas cuando el Merged Manifest muestre que los permisos vienen de una dependencia. Añade el namespace tools al elemento manifest si falta.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<!-- Las subidas usan el selector del sistema; no hace falta acceso amplio a los medios -->
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" tools:node="remove" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" tools:node="remove" />
<uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" tools:node="remove" />
</manifest>Breve y verificable. Indica el version code que lo corrige y el camino exacto en el que el revisor puede probar una subida. La plantilla se queda en inglés porque los revisores de Google la leen en inglés.
App: [App name], package name [com.example.app]. Rejected version code [123], new version code [124]. The app needs only occasional access to photos: users attach a single image to [their profile / a support request / a listing]. We removed READ_MEDIA_IMAGES and READ_MEDIA_VIDEO from version code [124] and from every active track, including internal and closed testing. Uploads now go through the Android system picker, which shares only the image the user selects. To verify: log in with the account in Sign-in details, open [Profile > Edit profile], tap [Change photo] and choose an image. Thank you for reviewing version code [124].
Sí. Un campo de archivo abre el selector del sistema, que comparte el archivo seleccionado sin ningún permiso multimedia amplio. Después del cambio, prueba el flujo una vez en Android 13 o posterior.
Sí, READ_MEDIA_VIDEO está sujeto a las mismas normas. Un vídeo seleccionado se puede compartir a través del selector igual que una foto; si tu app acepta subidas de vídeo, inclúyelas en tu ronda de pruebas.
Probablemente no. Publicar fotos seleccionadas es justo para lo que sirve el selector. El acceso amplio está pensado para apps cuya función principal no puede cubrir el selector, como los gestores de galería, y la declaración tiene que explicar por qué el selector es técnicamente insuficiente.
Google comprueba los permisos de cada bundle que envías con la política vigente, y una versión nueva de una biblioteca puede añadir entradas al manifiesto. La pestaña Merged Manifest muestra de qué archivo viene cada permiso.
No. CAMERA es un permiso aparte con su propia justificación. Consérvalo solo si alguna función hace fotos o escanea códigos, y quítalo en caso contrario.
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Ver planes en la página principal$349 por licencia, complemento de pago único
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Cómo funciona el Cloud Builder Prueba la demo gratuita$698 por plataforma $798
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Detalles del Full Service Con tecnología de
Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.
Garantía de aprobación en App Store & Google Play – o te devolvemos el dinero en 14 días
¿Prefieres delegarlo? Full Service: configuramos, compilamos y entregamos en 72 horas, desde $698 por plataforma. ¿Preguntas? Chatea con nosotros 24/7.
Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.