¿Por qué la aplicación de Android vuelve a una versión anterior después del apagado del dispositivo?

11

Observé este comportamiento muy extraño con la aplicación de Android. Escenario aproximado:

  1. Versión A instalada en el dispositivo
  2. La aplicación funciona bien
  3. Versión B instalada en el dispositivo (B> A)
  4. La aplicación funciona bien
  5. El dispositivo se apaga debido al agotamiento de la batería
  6. Dispositivo encendido
  7. La versión A de la aplicación se ejecuta nuevamente en el dispositivo

Información adicional:

  • La aplicación no se distribuye a través de Google Play, sino que se instala en las instalaciones a través de una conexión USB (NOTA: la aplicación se ejecuta en producción; no se instala a través de AndroidStudio).
  • Quiosco
  • Android 5.1 (API 22)

Creo que tengo dos preguntas:

  • ¿Por qué el dispositivo almacenó en caché la versión anterior del APK (y dónde lo almacenó)?
  • ¿En qué circunstancias pueden las aplicaciones volver a versiones anteriores como esa?

Editar (más información):

  • Parece que después de que el APK se revierte, la aplicación pierde algunos permisos (tal vez incluso todos). Funcionalidad que funcionaba antes de que la reversión dejara de funcionar debido a que se lanzaba SecurityException desde las API de Android. Esto sucede a pesar de que esta versión de Android todavía no tiene permisos de tiempo de ejecución.
  • Después de navegar por el sistema de archivos de la tableta, de hecho me veo APK varias de aplicaciones que residen en virtud de caminos similares: /data/app/com.myapp-2/base.apk, /data/app/com.myapp-3/base.apk, etc.

Mi hipótesis actual es que el agotamiento de la batería hace que la tableta "restablezca" su estado (por ejemplo, el reloj también se restablece), y cuando se vuelve a encender se confunde entre los APK de la aplicación y carga el incorrecto.

Sin embargo, no tengo idea de por qué haría eso o cómo prevenir este comportamiento.

Vasiliy
fuente
También me enfrenté a este comportamiento. tal vez esto ocurra debido a la ejecución instantánea, ya que divide el apk y el dispositivo de reinicio interrumpe el proceso y retrocede a la versión anterior.
touhid udoy
¿Estás utilizando diferentes usuarios en estos dispositivos? Tal vez una sesión de invitado a uno?
tynn
Esto podría ser específico del dispositivo (configuración de caché predeterminada). ¿Has probado en otros dispositivos?
Taslim Oseni
¿Lo probaste en el emulador de Android?
Squti
@TaslimOseni, hay un modelo específico de tableta utilizada para la implementación en el campo. Además, no es algo que se reproduzca fácilmente. Lo vimos solo una vez en el laboratorio.
Vasiliy

Respuestas:

2

Si está utilizando Android Studio 3.5+, entonces, en lugar de la ejecución instantánea, es probable que esté utilizando Aplicar cambios.

Esto tiene una forma diferente de enviar cambios al dispositivo, sin reescribir el apk, así que tenga mucho sentido que después de reiniciar, el apk que ejecutará si ejecuta su aplicación directamente en el dispositivo, no tiene nada que ver con el eso estaba funcionando antes

Aplicar cambios

Instant Run y ​​rediseñado e implementado desde cero un enfoque más práctico en Android Studio 3.5 llamado Apply Changes. Apply Changes utiliza API específicas de la plataforma de Android Oreo y superior para garantizar un comportamiento confiable y consistente; a diferencia de Instant Run, Apply Changes no modifica su APK.

https://android-developers.googleblog.com/2019/08/android-studio-35-project-marble-goes.html

Carlos Robles
fuente
Este problema ocurre en producción y la aplicación no está instalada en dispositivos a través de AndroidStudio. ¿Qué tienen que ver los cambios instantáneos o de aplicación?
Vasiliy
oh, lo siento, asumí que ya que mencionaste "La aplicación no se distribuye a través de Google Play, sino que se instala en las instalaciones a través de una conexión USB", así que automáticamente pensé en Android Studio. Después de su actualización, está claro. Pensaré un poco más ...
Carlos Robles
1

Esto enumera los paquetes instalados por el usuario:

adb shell cmd package help

pm list packages -f -U -3 --show-versioncode

Y luego desinstale completamente antes de reinstalar:

adb uninstall com.myapp

Con la ejecución instantánea y sin aplicar el parche APK (ver la pmsalida de ayuda), esto podría ejecutar el APK base. Esto no revierte nada, pero es probable que un APK sin el otro APK esté sobrecargado (Android Studio podría automatizar la aplicación del parche en caliente, pero en el momento del arranque, este podría no ser el caso). No usar la ejecución instantánea elimina estas actualizaciones de parches APK; y cuando solo hay un APK, no hay nada más que ejecutar.

Martin Zeitler
fuente
3
Lo siento, no veo cómo esto responde alguna de mis preguntas. También puedo ir y borrar manualmente estos archivos a través de ADB, pero, en este punto, quiero entender por qué sucede esto.
Vasiliy
@Vasiliy probablemente porque Dalvik VM está manejando APK parche de ejecución instantánea de manera diferente. La pregunta real es, ¿por qué hay incluso dos instancias diferentes de supuestamente lo mismo en diferentes versiones?
Martin Zeitler
No estoy seguro de qué tiene que ver la ejecución instantánea con todo esto. Los APK no se instalaron a través de AndroidStudio. Como usted dice, una de las preguntas es "por qué hay múltiples instancias de APK para la misma aplicación", pero no veo cómo responde su respuesta ...
Vasiliy
@Vasiliy no debería haber múltiples APK para comenzar, y si es así, entonces debe aplicarse el parche APK. Hay una diferencia entre "aplicar cambios" y el tiempo de arranque.
Martin Zeitler
1

¿Por qué el dispositivo almacenó en caché la versión anterior del APK (y dónde lo almacenó)?

El truco aquí está en el código de la versión. Cuando instale una nueva versión, asegúrese de que la nueva versión tenga un código de versión diferente . El sistema operativo Android utiliza códigos de versión para diferenciar entre diferentes versiones del mismo APK, por lo que esto funcionaría.

No está realmente claro por qué ocurre esta reversión. Obviamente, este es un extraño problema específico del dispositivo, pero, sin embargo, una gran cantidad de factores podrían ser responsables, incluidos el instalador predeterminado del dispositivo, la configuración de almacenamiento / caché, la memoria del dispositivo, los virus, etc.


Espero que esto ayude. Feliz codificación!

Taslim Oseni
fuente
1
Todavía no hemos resuelto el problema, pero como su respuesta es la única que, en teoría, podría estar relacionada, ¡la recompensa es suya!
Vasiliy