Google Play pronto obligará a los desarrolladores a cargar App Bundles en lugar de APK, lo que generará incómodas preguntas de seguridad sobre el requisito.
Pasado noviembre, Google anunció que los desarrolladores deberán publicar nuevas aplicaciones en Play Store utilizando el formato Android App Bundle (AAB) en lugar de un APK. El otro día, Google recordó a los desarrolladores este próximo requisito, lo que desató una tormenta de controversia. de usuarios que creen que Google está acabando con los APK, eliminando la descarga, obstaculizando las tiendas de aplicaciones de terceros y cualquier cosa.
Es cierto que los paquetes de aplicaciones de Android son una desviación bastante grande del formato APK clásico al que podrías estar acostumbrado, tanto como usuario como desarrollador. Si bien el uso de App Bundles tiene bastantes beneficios, hay un aspecto clave para crearlos que preocupa con razón a algunos desarrolladores y expertos en seguridad.
En este artículo, cubriremos las críticas que hemos visto sobre el cambio a Android App Bundles, así como algunas soluciones propuestas, y también hablaremos sobre la solución propuesta por Google para estos problemas.
Fondo
Sin embargo, antes de que eso suceda, debemos hablar un poco sobre cómo funciona la distribución de aplicaciones en Android en general. Si ya sabe cómo funcionan la firma de aplicaciones y los paquetes de aplicaciones, puede omitir esta parte.
APK
En su mayor parte, las aplicaciones de Android se distribuyen dentro de archivos APK. Un APK contiene todo el código y los recursos de una aplicación, junto con algunas características de seguridad como un manifiesto de firma. Cuando se instala un APK, básicamente se copia a una carpeta específica y se agrega a una base de datos interna de aplicaciones instaladas.
Firmas
Durante la instalación, la firma de esa aplicación también se verifica para garantizar que sea válida. Si la aplicación ya está instalada, Android compara la firma de la nueva aplicación con la que ya está instalada. Si la firma no es válida o no coincide, Android se negará a instalar la aplicación.
Esa verificación de firmas es una parte importante de la seguridad en Android. Se asegura de que la aplicación que estás instalando sea válida y al menos provenga de la misma fuente que la que ya tenías instalada. Por ejemplo, si instala, digamos, Mi aplicación Lockscreen Widgets de Play Store, puedes estar razonablemente seguro de que fui yo quien lo firmó y que es auténtico. Si luego intenta instalar una actualización de Lockscreen Widgets desde algún sitio sospechoso de terceros y falla, sabrá que alguien manipuló ese APK, posiblemente para agregar malware.
La clave utilizada para firmar una aplicación es (idealmente) nunca liberado públicamente. Esto se conoce como clave privada. Luego, la clave privada se utiliza para generar la clave que se muestra en la firma de la aplicación, conocida como clave pública. Esto es lo que utilizan Android y las tiendas de aplicaciones para verificar la validez de una aplicación. No entraré en cómo se puede generar exactamente una clave pública sin exponer la clave privada, ya que implica mucha matemática de cifrado. Si quieres más detalles, consulta Documentación de Google sobre la firma de APK o investigar un poco sobre funciones matemáticas unidireccionales.
Otra característica de las firmas de aplicaciones es la capacidad de restringir permisos sólo a aplicaciones con firmas coincidentes. Android hace esto internamente para muchas funciones, donde solo las aplicaciones firmadas con la misma clave que el marco pueden acceder a ciertas funciones.
Paquetes de aplicaciones
Ahora que hemos brindado una descripción general rápida de los APK y las firmas, hablemos de los paquetes de aplicaciones. Aquí es donde entran los recursos APK. Los recursos son cosas como diseños, imágenes, audio, etc. Básicamente, son cualquier cosa que no sea código. Para admitir mejor diferentes configuraciones de pantalla y diferentes idiomas, los desarrolladores pueden crear múltiples versiones del mismo recurso que se utilizan según el dispositivo y el idioma.
Pero en un APK, todos esos recursos existen, sin importar cuál uses. Y ocupan espacio. Dependiendo de la complejidad de su aplicación, podría haber muchos recursos no utilizados para muchos dispositivos. Esto es para lo que están diseñados los App Bundles. Los desarrolladores pueden generar un App Bundle como un APK, y ese App Bundle puede luego cargarse en Play Store, tal como lo hace un APK.
Luego, Google usa ese paquete de aplicaciones para generar un montón de APK diferentes para diferentes configuraciones de dispositivos. Cada App Bundle solo contiene los recursos necesarios para esa configuración. Cuando un usuario va a descargar esa aplicación, se le entrega el APK generado que coincide con su configuración. Esto ayuda a reducir los tamaños de descarga e instalación de aplicaciones, ahorrando ancho de banda y espacio de almacenamiento.
Por supuesto, instalar un APK específico para su dispositivo significa que le resultará más difícil copiarlo en otro dispositivo e instalarlo sin problemas. Dependiendo de tu perspectiva, esto puede ser algo bueno o malo. Por un lado, dificulta la piratería, ya que los usuarios ya no tienen la aplicación completa. Por otro lado, dificulta el archivado legítimo de aplicaciones, por la misma razón.
Firma de aplicaciones
Dado que los paquetes de aplicaciones de Android no son APK, no puede simplemente abrir un archivo AAB e instalarlo directamente en un dispositivo. Cuando subes uno a Play Store, Google usa el paquete para generar diferentes archivos APK (sin firmar). Luego, esos APK deben firmarse antes de poder instalarse.
En lugar de pedirle al desarrollador que firme y vuelva a cargar los APK generados, Google gestiona la firma por sí mismo. Play Store usa una nueva clave que crea o le pide al desarrollador la clave que usa para firmar APK. Con cualquiera de las opciones, Google gestiona la firma pública para el desarrollador y proporciona una carga llave. Google utiliza la clave de carga para la verificación interna y se asegura de que el paquete de aplicaciones (o APK en algunos casos) que el desarrollador está cargando sea el correcto.
Si una clave de carga se ve comprometida o se pierde, los desarrolladores pueden solicitar una nueva y la clave de firma utilizada para distribuir la aplicación permanece sin cambios.
Hay mucho más sobre la firma de aplicaciones, pero esto es lo relevante para este artículo. Si lo deseas, puedes leer más sobre los paquetes de aplicaciones y el inicio de sesión de aplicaciones. este artículo de Medium de Wojtek Kaliciński.
Crítica
En teoría y en la práctica, los paquetes de aplicaciones son bastante buenos. Reducen el uso de datos y el tamaño de la instalación, todo sin que el usuario tenga que hacer nada. Pero debido a la forma en que se implementa, algunos desarrolladores e investigadores de seguridad han expresado su preocupación en los últimos meses. Antes de resumir estas preocupaciones, quiero tomarme un momento para decir que la mayor parte de lo que se escribe a continuación es directamente basado en una serie de artículos por el desarrollador Mark Murphy de Artículos comunes. Absolutamente deberías consultar sus artículos, ya que brindan más detalles y críticas desde la perspectiva de un desarrollador.
Seguridad
En el modelo de distribución clásico, un desarrollador mantiene privada la clave que utiliza para firmar un APK. Nunca se comparte con el público y sólo las personas autorizadas deben tener acceso a él. Esto garantiza que solo esas personas puedan generar un APK válido.
Pero si usa App Bundles en Play Store, Google es quien administra la clave que firma los APK que reciben los usuarios. El por defecto comportamiento de las nuevas aplicaciones cargadas en Google Play a partir de agosto de 2021 Es para Google crear su propia clave de distribución que mantiene privada del desarrollador.
Desarrolladores que envían nuevas aplicaciones hará que Google administre su clave privada por ellos de forma predeterminada, aunque los desarrolladores envíen actualizaciones a aplicaciones existentes puede seguir usando APK o pueden cambiar a la distribución AAB generando una nueva clave para que Google la utilice con nuevos usuarios. Aplicaciones existentes no son requeridos para cambiar de la distribución de APK a Android App Bundles, aunque esa opción está disponible si así lo desean. Después de algunas reacciones, Google incluso lo hará posible para cargar su propia clave privada para que Google inicie sesión, tanto para aplicaciones nuevas como existentes. Ninguna de estas situaciones es ideal, ya que pase lo que pase, Google tendrá acceso a su clave privada si así lo desea. use paquetes de aplicaciones de Android (y los desarrolladores no tienen otra opción al respecto si desean enviar una nueva aplicación después de agosto 2021!)
Si bien estamos seguros de que Google se toma muy en serio la seguridad, no hay ninguna empresa en el mundo que sea inmune a las filtraciones de datos. Si la clave que utiliza Google para firmar su aplicación para su distribución se encuentra en una de esas infracciones, entonces cualquiera puede firmar una versión de su aplicación y hacer que parezca que fue firmada por usted. Y algunos desarrolladores y expertos en seguridad no están contentos con esta posibilidad. Es una posibilidad muy, muy remota, sí, pero el hecho de que sea una posibilidad asusta a algunos en la comunidad de seguridad de la información.
Hacer que los desarrolladores firmen APK de Android significa que cualquiera puede verificar los APK desde Google Play, no se requiere confianza ciega. Es un diseño elegante que proporciona seguridad comprobable. Los paquetes de aplicaciones le dan la vuelta a esto y parecen estructurados para promover la dependencia del proveedor. Hay muchos enfoques técnicos alternativos que proporcionarían APK pequeños aún firmados por desarrolladores, pero estos no darían preferencia a Play. Por ejemplo, el desarrollador podría generar y firmar todas las variantes del APK y luego cargarlas en cualquier tienda de aplicaciones.
Ciertamente, existen argumentos sobre si es mejor dejar el almacenamiento seguro de claves privadas en manos de Google o de desarrolladores individuales. Pero esos desarrolladores (probablemente) no suelen utilizar un repositorio central para sus claves. Al obligar a los desarrolladores a utilizar Play App Signing, un atacante malintencionado sólo necesita violar la seguridad de Google una vez para recuperar miles o millones de claves.
Por si sirve de algo, esto es lo que dice Google sobre cómo protege su clave de firma en su infraestructura:
[blockquote Author="Wojtek Kaliciński, defensor de los desarrolladores de Android en Google"]Cuando utiliza Play App Signing, sus claves se almacenan en la misma infraestructura que Google utiliza para almacenar sus propias claves.
El acceso a las claves se rige por estrictas ACL y pistas de auditoría a prueba de manipulaciones para todas las operaciones.
Todos los artefactos generados y firmados con la clave del desarrollador están disponibles en Google Play Console para su inspección/certificación.
Además, para evitar la pérdida de claves, realizamos copias de seguridad muy frecuentes de nuestro almacenamiento principal. Estas copias de seguridad están fuertemente cifradas y probamos periódicamente la restauración a partir de estas copias de seguridad.
Si desea obtener información sobre la infraestructura técnica de Google, lea el Documentos técnicos sobre seguridad en la nube de Google.[/blockquote]
Por muy bueno que parezca, todos los ruidos, la pérdida y el robo siguen siendo posibles. Y las pistas de auditoría sólo ayudan a prevenir futuros ataques; No recuperarán las claves violadas.
Potencial de modificaciones no autorizadas
Un gran problema con la forma en que Google ha configurado los paquetes de aplicaciones es la posibilidad de que se agreguen modificaciones no autorizadas a una aplicación. El proceso de extracción de APK de un paquete de aplicaciones implica inherentemente modificaciones, ya que Google tiene que crear manualmente cada APK. Mientras Google ha prometido que no inyecta ni modificará código, el problema con el proceso App Bundle es que tiene el poder para hacerlo.
Aquí hay un par de ejemplos de lo que una empresa en la posición de Google tiene el poder de hacer:
Digamos que hay una aplicación de mensajería segura que la gente usa para comunicarse sin riesgo de vigilancia gubernamental. Esta podría ser una herramienta increíblemente útil para las personas que protestan contra un gobierno autoritario, o incluso para las personas que simplemente quieren mantener su privacidad. Ese gobierno, que quiere tener la capacidad de ver lo que dicen los usuarios de la aplicación, podría intentar obligar a Google a agregar una puerta trasera de vigilancia al código de la aplicación.
Este ejemplo es un poco más inofensivo, pero también es algo que preocupa a algunas personas. Digamos que hay una aplicación que recibe millones de descargas al día, pero no contiene anuncios ni análisis. Esa es una enorme fuente de datos a la que no hay forma de acceder a esos datos. Google, al ser una empresa de publicidad, podría querer acceder a esos datos.
En el modelo APK clásico de distribución de aplicaciones, Google no puede modificar las aplicaciones sin cambiar la firma. Si Google cambia la firma, especialmente en una aplicación popular, la gente se dará cuenta porque la actualización no se instala. Pero con App Bundles y App Signing, Google podría inyectar silenciosamente su propio código en las aplicaciones antes de distribuirlas. La firma no cambiaría porque Google sería propietario de la clave de firma.
Para ser claro, Es increíblemente improbable que estos ejemplos sucedan.. Google tiende a simplemente retirarse por completo de los mercados problemáticos, en lugar de adaptarse. Pero aunque sea poco probable, aún es posible. El hecho de que una empresa prometa que algo no sucederá no lo garantiza.
Transparencia del código
Google, al escuchar estas preocupaciones, introdujo esta semana una nueva función llamada Transparencia de código para paquetes de aplicaciones. Code Transparency permite a un desarrollador crear esencialmente una segunda firma que se envía con la aplicación a los usuarios. Esta firma adicional debe crearse a partir de una clave privada separada a la que solo tenga acceso el desarrollador. Sin embargo, existen algunas limitaciones para este método.
La transparencia del código solo cubre el código. Esto puede parecer obvio dado el nombre, pero también significa que no permite a los usuarios verificar recursos, el manifiesto o cualquier otra cosa que no sea un archivo DEX o una biblioteca nativa. Si bien las modificaciones maliciosas a archivos sin código suelen tener mucho menos impacto, sigue siendo un agujero en la seguridad de la aplicación.
Otro problema con Code Transparency es que no existe una verificación inherente. Para uno, es una característica opcional, por lo que los desarrolladores deben recordar incluirlo en cada nuevo APK que carguen. De momento hay que hacerlo desde línea de comandos y con una versión de bundletool eso no viene con Android Studio. Incluso cuando un desarrollador lo incluye, Android no tiene ningún tipo de verificación incorporada para verificar que el manifiesto de Transparencia del Código coincida con el código de la aplicación.
Depende del usuario final comprobarlo por sí mismo comparando el manifiesto con una clave pública que el desarrollador puede proporcionar o enviando el APK al desarrollador para su verificación.
Si bien Code Transparency permite confirmar que no se modifica ningún código en una aplicación, no incluye ningún tipo de verificación para otras partes de una aplicación. Tampoco existe una confianza inherente en el proceso. Se podría argumentar que si no confías en Google, probablemente estés a la altura de la tarea de verificarlo de forma independiente, pero ¿por qué deberías hacerlo?
Hay otros problemas con la función Transparencia de código, como señaló por Mark Murphy de Artículos comunes. Recomiendo leer su artículo para un análisis más profundo de la función.
Comodidad y elección del desarrollador
Una tercera (y última de este artículo) razón por la que algunos desarrolladores tienen problemas con los App Bundles es la menor comodidad y opciones.
Si un desarrollador crea una nueva aplicación en Play Store después de que Google comienza a requerir App Bundles y elige la opción predeterminada de permitir que Google administre la clave de firma, nunca tendrán acceso a esa firma llave. Si ese mismo desarrollador quiere distribuir esa aplicación en otra tienda de aplicaciones, tendrá que usar su propia clave, que no coincidirá con la de Google.
Eso significa que los usuarios tendrán que instalar y actualizar desde Google Play o desde fuentes de terceros. Si quieren cambiar la fuente, deben desinstalar completamente la aplicación, lo que podría perder datos, y volver a instalarla. Agregadores de APK como APKMirror Entonces también tendrá que lidiar con múltiples firmas oficiales para la misma aplicación. (Técnicamente, ya tienen que hacer esto porque la firma de aplicaciones le permite crear una clave nueva y más segura para los nuevos usuarios, pero será peor para ellos y para otros sitios cuando todos tiene para hacerlo.)
La respuesta de Google a este problema es utilizar el explorador de paquetes de aplicaciones o el explorador de artefactos en Play Console para descargar los APK resultantes del paquete cargado. Al igual que Code Transparency, esta no es una solución completa. Los APK descargados desde Play Console se dividirán para diferentes perfiles de dispositivos. Si bien Play Console admite la carga de varios APK para una versión de una aplicación, muchos otros canales de distribución no lo hacen.
Por lo tanto, muchos de los beneficios del uso de App Bundles desaparecen cuando los desarrolladores administran varias tiendas, lo que dificulta la distribución. con noticias que ventanas 11 es obteniendo soporte para aplicaciones de Android Gracias a Amazon Appstore, algunos creen que el requisito de App Bundles desincentivará a los desarrolladores a distribuir en Amazon. Por supuesto, la principal preocupación de Google es su propia tienda de aplicaciones, pero eso es exactamente lo que los metió en problemas con los competidores llevándolos a hacer pequeños cambios conciliadores sobre cómo funcionan las tiendas de aplicaciones de terceros en Android.
Un par de problemas relacionados con varias tiendas son la interconectividad de aplicaciones y las pruebas rápidas.
Comencemos con la interconectividad de aplicaciones. ¿Alguna vez has descargado una aplicación que bloquea funciones detrás de un muro de pago? Casi definitivamente. Algunos desarrolladores incluyen las funciones detrás de una compra dentro de la aplicación, pero otros pueden optar por crear una aplicación paga por separado. Cuando se instala esa aplicación complementaria, las funciones de la aplicación principal se desbloquean.
Pero, ¿qué impide que alguien instale el complemento desde una fuente pirata? Bueno, hay muchas opciones para los desarrolladores, pero al menos una implica el uso de permisos protegidos por firma. Digamos que la aplicación principal declara un permiso protegido por firma. Luego, la aplicación complementaria declara que quiere utilizar ese permiso. Idealmente, la aplicación complementaria también tendrá algún tipo de función de verificación de licencia, que se conecta a Internet para garantizar que el usuario sea legítimo.
Si ambas aplicaciones tienen la misma firma, Android otorgará permiso a la aplicación complementaria y pasarán las comprobaciones de protección contra piratería. Si la aplicación complementaria no tiene la firma correcta, no se otorgará el permiso y la verificación fallará.
Con el modelo clásico de distribución de APK, un usuario puede obtener cualquiera de las aplicaciones de cualquier fuente legítima y terminar con ella. Con el modelo de paquete de aplicaciones predeterminado actual, las firmas de las aplicaciones principal y complementaria no coincidirán. Google creará una clave única para cada aplicación. El desarrollador siempre podría eliminar el permiso protegido por firma y utilizar la verificación directa del hash de la firma, pero eso es mucho menos seguro.
Y luego están las pruebas rápidas. Los usuarios envían correos electrónicos a los desarrolladores todo el tiempo sobre problemas en sus aplicaciones. A veces, esos problemas son soluciones simples: reproducir el problema, encontrarlo, solucionarlo y cargar una nueva versión. Pero a veces no lo son. A veces los desarrolladores no pueden reproducir un problema. Pueden solucionar lo que creen que es el problema, pero luego el usuario tiene que probarlo. Ahora supongamos que el usuario instaló la aplicación a través de Google Play.
Con el modelo APK, un desarrollador puede cambiar algún código, crear y firmar un nuevo APK y enviárselo al usuario para que lo pruebe. Dado que la firma del APK de prueba coincide con la que el usuario ha instalado, es un proceso sencillo actualizar, probar e informar. Con App Bundles, esto se desmorona. Dado que Google firma el APK que el usuario instaló originalmente, no coincidirá con la firma del APK que envía el desarrollador. Si esta aplicación se publica después de la fecha límite de App Bundles, el desarrollador ni siquiera tendrá acceso a las claves que utiliza Google. Para realizar la prueba, el usuario deberá desinstalar la aplicación actual antes de instalar la versión de prueba.
Hay muchos problemas aquí. En primer lugar, existen inconvenientes, tanto para el desarrollador como para el usuario. Tener que desinstalar la aplicación sólo para probar una solución no es divertido. ¿Y si el problema desaparece? ¿Fueron los cambios que realizó el desarrollador o fue porque el usuario borró efectivamente los datos de la aplicación? Play Store tiene pruebas internas, que se supone que permiten a los desarrolladores realizar compilaciones y distribuciones rápidas, pero requiere que el usuario desinstale primero la versión de lanzamiento. Realmente no soluciona nada.
En caso de que todo esto parezca un montón de hipotéticas tonterías, aquí hay un ejemplo muy real de un desarrollador que tendrá estos problemas si deja que Google le genere una clave privada: João Dias. Es el desarrollador de Tasker, junto con una gran cantidad de aplicaciones complementarias, incluida la suite AutoApps. Con el nuevo requisito de App Bundles, el ciclo de desarrollo de João puede volverse mucho más complicado, al menos para las nuevas aplicaciones. Enviar versiones de prueba directamente será menos conveniente. La verificación de licencias será menos efectiva.
Esto puede parecer un caso extremo, pero no es que João sea un pequeño desarrollador, y es probable que no esté solo. Hay muchas aplicaciones en Play Store que se basan en la verificación de firmas para detectar usuarios ilegítimos.
Por supuesto, con la nueva opción para que los desarrolladores carguen sus propias claves de firma en Google, estos problemas se alivian al menos un poco. Pero los desarrolladores deben optar por habilitar la opción para cada aplicación. Si no lo hacen, las interconexiones fallarán y el soporte rápido requerirá cargar un paquete en Google y esperar a que se generen los APK antes de enviar el correcto al usuario. Además, todavía significa que tienen que compartir su clave privada, lo que nos lleva de nuevo a las preocupaciones que discutimos anteriormente.
Soluciones
Este es un problema antiguo dado que los requisitos del App Bundle se publicaron hace meses, por lo que se han propuesto bastantes soluciones mientras tanto.
Una solución es evitar la necesidad de firmar la aplicación Play. En lugar de generar un paquete de aplicaciones que luego Google procesa en APK y firma, Android Studio podría realizar ese procesamiento. Luego, los desarrolladores pueden simplemente cargar un ZIP lleno de APK firmados localmente para cada configuración que Google habría generado.
Con esa solución, Google no necesitaría ningún acceso a las claves de los desarrolladores. El proceso sería muy similar al modelo de distribución de APK clásico, pero involucraría varios APK más pequeños en lugar de solo uno.
Otra solución es simplemente no exigir el uso de App Bundles y seguir permitiendo a los desarrolladores cargar APK firmados localmente. Si bien los paquetes de aplicaciones pueden ser una mejor experiencia para el usuario en muchos casos, algunas aplicaciones en realidad no se benefician de estar divididas por configuración, con un tamaño mínimo reducción.
Si Google implementó ambas soluciones, entonces un desarrollador que quiera usar App Bundles no tendrá que hacerlo. en lugar de firmar con Google, y un desarrollador cuya aplicación no se beneficiará mucho del formato no tendrá que usarlo en todo.
Las respuestas de Google
Autofirma
Cuando se les preguntó por primera vez sobre permitir a los desarrolladores gestionar la firma de paquetes de aplicaciones, la respuesta de Google fue muy evasiva:
[blockquote Author=""]Entonces, hablé brevemente sobre el requisito del próximo año para que las nuevas aplicaciones usen paquetes de aplicaciones, y una cosa que viene con eso es que, por extensión, requeriremos la firma de aplicaciones de Play. Por lo tanto, los desarrolladores deberán generar la clave de firma de aplicaciones en Play o cargar su propia clave en Play... porque ese es un requisito previo para los paquetes de aplicaciones. Hemos escuchado de los desarrolladores que algunos de ellos simplemente no quieren hacerlo. No quieren que Play administre las claves. Y actualmente eso no es posible si desea utilizar paquetes de aplicaciones.
Pero hemos escuchado esos comentarios y... no puedo hablar de nada en este momento, no tenemos nada que anunciar, pero estamos investigando cómo podríamos aliviar algunas de estas preocupaciones. No necesariamente tiene que permitir conservar su propia clave mientras carga paquetes. Estamos analizando diferentes opciones. Simplemente no tenemos una solución que anunciar en este momento. Pero todavía nos queda alrededor de un año hasta que se cumpla el requisito, por lo que tengo muchas esperanzas de que tengamos una respuesta para los desarrolladores.[/blockquote]
Eso fue a finales de noviembre del año pasado y no parece haber sucedido nada. Faltando sólo unos meses para la El requisito de App Bundles entra en vigor, todavía no hay una manera para que los desarrolladores manejen la firma de sus propias aplicaciones. Si bien Google ahora ha hecho posible subir su propia clave para aplicaciones nuevas y existentes, esto todavía quita la parte de firma de las manos del desarrollador.
Cambios de código
Si bien Google ha prometido específicamente que Play Store no modificará el código de la aplicación, una promesa no es una garantía. Con los paquetes de aplicaciones y la firma de aplicaciones, no conocemos ninguna limitación técnica que impida que Google modifique las aplicaciones cargadas antes de su distribución.
Google ha presentado Transparencia del código como característica opcional, y si bien esto ayuda un poco, tiene una buena cantidad de problemas, como comentamos anteriormente.
Paquetes hechos a sí mismos
Cuando se le preguntó a Google sobre permitir a los desarrolladores crear sus propios "paquetes" de aplicaciones (ZIP que contienen APK divididos), la respuesta fue básicamente "no vamos a hacer eso":
Probablemente no como se describe en la pregunta, ya que esto dificultaría aún más el proceso de publicación para los desarrolladores y, de hecho, queremos hacerlo más simple y seguro. Sin embargo, nuevamente, hemos escuchado estos comentarios y buscaremos opciones para hacerlo posible, aunque probablemente no de la manera que se describe aquí.
Curiosamente, la justificación de Google parece ser que complicaría la publicación. Sin embargo, Google aún podría automatizar el proceso como parte del cuadro de diálogo de generación de APK en Android Studio. Además, si la aplicación en cuestión se distribuye en varias tiendas, en realidad haría que la aplicación proceso de publicación más simple, ya que los desarrolladores no tendrían que administrar múltiples claves de firma y quejas de usuarios.
Y con la introducción de Code Transparency, parece que la complicación no es exactamente un problema después de todo. Code Transparency, al menos por ahora, requiere que el desarrollador utilice una herramienta de línea de comandos y que los usuarios verifiquen explícitamente la validez de la aplicación que reciben. Esto es más complicado que un proceso para crear paquetes usted mismo y no está claro por qué esta es la solución que prefiere Google.
Avanzando
Los paquetes de aplicaciones serán el formato de distribución requerido para las nuevas aplicaciones enviadas a Google Play a partir del 1 de agosto. Si bien Google ha abordado al menos en parte la mayoría de las cuestiones planteadas por los desarrolladores y expertos en seguridad, las respuestas dejan mucho que desear. Hay muchos beneficios obvios para los App Bundles como formato de distribución de próxima generación, pero siempre habrá preocupaciones persistentes sobre otorgar control parcial o total de la firma de aplicaciones a Google.
Las respuestas y los esfuerzos de Google ciertamente son apreciados, pero algunos, como Mark Murphy, sienten que no han ido lo suficientemente lejos. Con soluciones como paquetes de fabricación propia que no se implementan y la fecha límite para los paquetes de aplicaciones de Android se exige rápidamente A medida que se acerca, no parece que los desarrolladores de Google Play puedan mantener el control total de sus aplicaciones por mucho tiempo. más extenso.
Hablaremos sobre las implicaciones del requisito del Android App Bundle en un espacio de Twitter esta tarde, ¡así que únete a nosotros!