No es la primera vez que hablo por estos lares de la retrocompatibilidad.
Ese paradigma del desarrollo del software por el cual, de cara a evolucionar un producto, se tiene en cuenta que esa pieza de código debe poder también ejecutarse en dispositivos antiguos.
La retrocompatibilidad es pilar fundamental de la electrónica de consumo de nuestra época, por la sencilla razón de que no todo el mundo puede permitirse comprar un nuevo dispositivo cada vez que sale una nueva versión. Máxime en ciclos evolutivos anuales, como parece que empieza a ser la máxima de la industria digital.
Índice de contenido
Los límites de la retrocompatibilidad
Sin embargo, el quid de la cuestión está en saber hasta qué punto se debe o no permitir la retrocompatibilidad. Y aquí hay opiniones para todos los gustos.
- Por un lado, están aquellos como Apple cuya retrocompatibilidad tiende a ser efectiva durante las dos o tres versiones anteriores (móviles), y tras los cinco o seis años en escritorio. Esto, desde el punto de vista de la seguridad, es muchísimo más adecuado, a sabiendas de que tienes que tener en cuenta muchísimos menos factores que podrían llegar a comprometer la seguridad y/o privacidad de la información almacenada en los mismos. Pero por supuesto, también rema a contracorriente del interés del cliente medio de electrónica de consumo, habida cuenta de que cada dos o tres años su dispositivo quedaría desfasado, y poco más adelante, empezaría a tener problemas para ejecutar algunas de las funcionalidades nuevas tanto del sistema operativo como de las herramientas y aplicaciones de terceros.
- Por otro, está la postura de Microsoft o Google, que ofrecen mayores ciclos de retrocompatibilidad a cambio de tener que operar en un ecosistema cada vez más complejo. De nuevo, el cliente medio de este tipo de productos va a demandar por lo general mayor retrocompatibilidad, obviando seguramente que ello conlleva una exposición y riesgo mayor.
Windows 10S, por seguir con el símil, no deja de ser el enésimo intento de Microsoft por re-educar al cliente en la necesidad de ceder libertades a cambio de control (ergo, seguridad). Un sistema operativo «capado» (al igual que pasa con MacOS), en el que todo lo que se instale vendrá con el sello del market oficial, asegurando así el nivel de usabilidad, privacidad y seguridad que la compañía espera que el usuario tenga delante del dispositivo.
La tendencia de estos últimos años, por tanto, está dándole la razón a Apple. El propio principio de los sistemas operativos móviles va justo hacia esa dirección, ofreciendo por un lado un «único» vector de entrada de nuevas herramientas (el market oficial de aplicaciones), y por otro, la creación de sandboxings en los que cada aplicación corre por separado, únicamente capaz de comunicarse con el resto de elementos del sistema (y de otras aplicaciones) mediante espacios en común que requieren pedir expresamente una serie de permisos.
Pero un cambio hacia entornos más centralizados (para bien y para mal) no puede hacerse drásticamente. Y esa aventura, todavía heredamos una mochila histórica de errores que nos vienen dados de épocas pasadas.
Ese es el caso del permiso READ_PHONE_STATE (EN).
Riesgos debidos a la retrocompatibilidad
Como explicaban hace unas horas en El Androide Libre (ES), es aún muy habitual que la mayoría de aplicaciones que tenemos instaladas en nuestro dispositivo pidan acceso a un permiso denominado «ID de dispositivo y datos de llamada».
Con él, el desarrollador de esa aplicación puede conocer el ID del dispositivo, nuestro número de teléfono, y un buen número de elementos identificativos del mismo, así como establecer en qué estado se encuentra el terminal.
En mi caso, por ejemplo, de 92 aplicaciones que tengo instaladas en el dispositivo (piense que estoy también teniendo en cuenta aplicaciones nativas en Android), 56 han pedido este permiso, y hoy en día se lo he concedido a 16 de ellas, bajo alertas del tipo «Si deniegas este permiso, es posible que algunas funciones básicas de tu dispositivo dejen de funcionar correctamente» o «Esta aplicación está diseñada para una versión anterior de Android. Si se le deniega el permiso, puede dejar de funcionar de la forma prevista».
¿La razón principal que esgrimen casi todos los desarrolladores?
Que es la manera más sencilla de saber si el dispositivo está o no en una llamada. Lo que permite bloquear por ejemplo un juego, o silenciar el sonido de una app de música o podcast, y volver a recuperarlo una vez la llamada ha terminado.
¿De verdad más de la mitad de mis aplicaciones necesitan acceder a este permiso?
Lo cierto es que no. Es más, la amplia mayoría, por no decir todas, podrían hacer exactamente lo mismo si hicieran uso de Audio Manager (EN), una herramienta nativa de Android que permite saber en todo momento si el dispositivo está o no reproduciendo sonido, con la ventaja de no necesitar acceder también a datos personales identificativos.
Pero entonces, ¿por qué no lo hacen?
Porque Audio Manager solo está disponible… a partir de Android 6 Marshmallow.
Lo que quiere decir que aunque mi dispositivo sí podría beneficiarse de esta medida de seguridad, en la práctica no lo hace debido a que los desarrolladores deben anteponer la retrocompatibilidad a «factores secundarios» como es la privacidad y seguridad de la información.
¿Qué se podría hacer para minimizar el impacto nocivo de la retrocompatibilidad?
Hay dos caminos alternativos, y la idea es que se recorran de forma paralela.
- La modularidad: Todo apunta a que Android está preparándose para afrontar la fragmentación (un efecto nocivo, precisamente, de la retrocompatibilidad y apertura de desarrollos que ofrece este sistema operativo) mediante una suerte de modulación de los componentes que lo forman. Esto permitiría asegurar que al menos una parte crítica del sistema está siempre actualizada en todo su parqué de dispositivos. Y de esta manera, se llega a un equilibrio bastante santo entre los beneficios que da la retrocompatibilidad al usuario, y los sacrificios que hay que hacer para tenerla. El cliente final podría tener dispositivos de hace varios años que aún seguirían recibiendo actualizaciones críticas para el kernel, y los desarrolladores tendrían entonces que preocuparse menos por utilizar funciones consideradas inseguras cuyas alternativas ya solventan estos problemas.
- El desarrollo segmentado: Android ya ofrece desde sus inicios la capacidad de segmentar desarrollos por dispositivos, mercados y un sin fin de características. Y esto puede hacerse mediante desarrollos distintos dependiendo del segmento al que van destinados, o mediante el mismo desarrollo cuyas funciones dependan de la tipología de segmento donde va a ejecutarse. Cualquier desarrollador podría ofrecer hoy en día la misma aplicación pidiendo o no dicho permiso según el dispositivo donde vaya a ser ejecutada cuenta con Audio Manager o no. De esta manera, no tendríamos que pagar justos por pecadores aquellos que tenemos versiones más actualizadas.
Confío que dentro de unos años este tipo de problemas no sean la tónica de la jornada. Parece que poco a poco vamos aprendiendo. Pero, por ello, no estaría de más que aplicaciones de la talla de Spotify, Facebook, Netflix o Youtube dieran el primer paso, adaptando sus desarrollos según el segmento al que van a ir dirigidos, y utilizando para cada caso la alternativa menos invasiva recomendada por Google.
Sobra decir, por cierto, que de cara al usuario cualquiera puede desactivar este permiso en la mayoría de aplicaciones que utiliza, que presumiblemente seguirán funcionando igual, con la salvedad de que no serán capaces de bloquearse cuando entra una llamada, o volver a activarse cuando esta llamada termina.
Para ello, como siempre, la opción debería estar por Ajustes > Aplicaciones > entrar en cada una de ellas > Permisos, o bien en la aplicación/enlace de Permisos que tenga la ROM que utilicemos.
