Permisos: normales, peligrosos y los que la app pide sin usar

Según la documentación oficial de Android, los permisos de instalación se conceden al instalar la app. Entre ellos están los normales, que dan acceso a datos o acciones de riesgo mínimo para la privacidad, y los de firma, que solo se conceden a quien comparte certificado con la app o el sistema que los define. Los permisos peligrosos, en cambio, dan acceso a datos sensibles y exigen que el usuario los apruebe en tiempo de ejecución: la ubicación, los contactos, la cámara, el micrófono o los mensajes.

Para una revisión, el nivel decide la prioridad: un permiso peligroso sobrante es un hallazgo; uno normal casi nunca lo es. Los permisos propios de la app, definidos en su manifiesto, suelen ser de firma: sirven para que solo otras apps de la misma empresa llamen a sus componentes.

El analizador estático busca en el código las referencias a cada permiso declarado. Un permiso con cero referencias es un permiso que la aplicación pide y no necesita: no hace nada útil, y si el permiso es peligroso, deja a la app con acceso a datos que no usa, y a un usuario con un diálogo de más. Si la aplicación se compromete por otro lado, ese acceso sobrante lo hereda quien la controle.

La medida es el mínimo privilegio: quitar de la declaración lo que no se usa. A veces el permiso es herencia de una biblioteca o de una función retirada, así que el hallazgo se redacta como «declarado sin uso» y se confirma con el equipo antes de proponer la baja.

Un número honesto abre el informe: cuántos permisos peligrosos declara la app. No cuenta el total de permisos, porque los normales casi no pesan, ni cuenta los que el usuario podría negar por su cuenta. Cuenta los que el manifiesto declara con nivel peligroso. Es un indicador de superficie, no de culpa: una app de mapas tiene más que una calculadora, y cada uno se justifica o no por la función.

El número se obtiene de la lista de permisos declarados y de su nivel de protección. Se anota junto a los permisos que se justifican por función, para que el lector vea cuántos de los peligrosos tienen una razón visible en la app.

Una aplicación puede definir sus propios permisos, normalmente de nivel de firma, para proteger sus componentes frente a otras apps. Definir el permiso no basta: hay que aplicarlo a los componentes, con el atributo permission o con los atributos de lectura y escritura de un proveedor. Un permiso definido y no aplicado es una intención que no llegó a ejecutarse, y suele aparecer en el análisis como «definido, no aplicado».

Este caso conecta con la sala anterior: el proveedor de recibos exportado sin permiso estaba pidiendo a gritos una protección, y la app tenía una definida. La corrección es aplicarla, no definir otra.

La medida de un hallazgo de permisos tiene dos caras. Para el permiso peligroso sin uso: quitarlo del manifiesto, tras confirmar que ninguna función ni biblioteca lo necesita. Para el permiso propio sin aplicar: aplicarlo al componente que debía proteger, y comprobar que las apps de la misma empresa que lo usan tienen la misma firma. En ambos casos la severidad se decide por lo que dejaría alcanzable, no por cuántos permisos haya.

Una medida mal redactada es la que pide «revisar los permisos» sin decir cuáles. Un informe útil nombra el permiso, el componente y el cambio exacto.