0 votos

¿Sustitución de la batería de la tablet y fallo de alloc_device_open?

Tuve que hacer un cambio de batería en una tablet Android 4.x Denver TAC-97032.

La batería había sido obtenida del fabricante como pieza de recambio; sin embargo, no es del mismo tamaño que la original.

Aun así, abrí el tablado, desoldé la batería vieja y soldé la nueva; el comportamiento a partir de entonces es:

  • Si sólo conecto el cargador, me aparece la animación de Android "la batería se llena" durante un rato, la animación muestra la carga y luego desaparece, como siempre. Bien - significa que la batería se detecta y se monta correctamente.
  • Si arranco con Power + Vol Up, entro en el recovery, que aquí sólo muestra la imagen de "Android muerto"; no hay menús extra para ADB sideload o similares, así que básicamente se queda ahí; adb también puede ver un dispositivo de "recuperación", y adb reboot también es reconocido y trabaja
  • Si arranco sólo con Power: primero aparece el splash de DENVER, luego se muestra una pantalla de inicio de Android, luego la pantalla se pone en negro (pero parece que todavía hay luz de fondo); el dispositivo parece muerto, pero si mantengo pulsado Power para forzar el apagado, al final se oye un clic del altavoz y se ve el flash de la pantalla - lo que significa que el dispositivo funcionó también bajo la pantalla negra.

En la pantalla negra, intenté adb - y por suerte, funcionó:

$ ./adb.exe logcat
--------- beginning of /dev/log/main
I//system/bin/e2fsck(   67): e2fsck 1.41.11 (14-Mar-2010)
I//system/bin/e2fsck(   67): /dev/block/nande: clean, 5183/76800 files, 205676/307200 blocks
I/logwrapper(   67): /system/bin/e2fsck terminated by exit(0)
I//system/bin/e2fsck(   72): e2fsck 1.41.11 (14-Mar-2010)
I//system/bin/e2fsck(   72): /dev/block/nandh: clean, 15/20496 files, 2623/81920 blocks
I/logwrapper(   72): /system/bin/e2fsck terminated by exit(0)
--------- beginning of /dev/log/system
I/USB3G   (   85): usb 3g monitor v0.1 start
I/USB3G   (   85): event { 'add', '/devices/platform/sw_hcd_host0/usb1', 'usb', '', 189, 0 }
I/USB3G   (   85): event { 'add', '/devices/platform/sw-ehci.1/usb2', 'usb', '', 189, 128 }
I/USB3G   (   85): event { 'add', '/devices/platform/sw-ohci.1/usb3', 'usb', '', 189, 256 }
I/Netd    (   80): Netd 1.0 starting
I/Vold    (   79): Vold 2.1 (the revenge) firing up
D/Vold    (   79): Volume sdcard state changing -1 (Initializing) -> 0 (No-Media)
D/Vold    (   79): Volume extsd state changing -1 (Initializing) -> 0 (No-Media)
D/Vold    (   79): Volume usbhost1 state changing -1 (Initializing) -> 0 (No-Media)
D/Vold    (   79): Volume sdcard state changing 0 (No-Media) -> 1 (Idle-Unmounted)
I/SurfaceFlinger(   81): SurfaceFlinger is starting
I/SurfaceFlinger(   81): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
E/[Gralloc-ERROR](   81): int alloc_device_open(const hw_module_t*, const char*, hw_device_t**):436 UMP open failed with 1
E/FramebufferNativeWindow(   81): couldn't open framebuffer HAL (Operation not permitted)
E/[Gralloc-ERROR](   81): int alloc_device_open(const hw_module_t*, const char*, hw_device_t**):436 UMP open failed with 1
E/FramebufferNativeWindow(   81): couldn't open gralloc HAL (Operation not permitted)
E/SurfaceFlinger(   81): Display subsystem failed to initialize. check logs. exiting...
I/        (   82): ServiceManager: 0xf958
I/AudioFlinger(   82): Loaded primary audio interface from sunxi audio HW HAL (audio)
I/AudioFlinger(   82): Using 'sunxi audio HW HAL' (audio.primary) as the primary audio interface
I/CameraService(   82): CameraService started (pid=82)
I/AudioFlinger(   82): AudioFlinger's thread 0x1c7b0 ready to run
W/AudioFlinger(   82): Thread AudioOut_1 cannot connect to the power manager service
I/AudioPolicyService(   82): Loaded audio policy from LEGACY Audio Policy HAL (audio_policy)
I/SurfaceFlinger(  129): SurfaceFlinger is starting
I/SurfaceFlinger(  129): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
I/[Gralloc](  129): using (fd=10)
I/[Gralloc](  129): id           =
I/[Gralloc](  129): xres         = 1024 px
I/[Gralloc](  129): yres         = 768 px
I/[Gralloc](  129): xres_virtual = 1024 px
I/[Gralloc](  129): yres_virtual = 1536 px
I/[Gralloc](  129): bpp          = 32
I/[Gralloc](  129): r            = 16:8
I/[Gralloc](  129): g            =  8:8
I/[Gralloc](  129): b            =  0:8
I/[Gralloc](  129): width        = 163 mm (159.568100 dpi)
I/[Gralloc](  129): height       = 122 mm (159.895081 dpi)
I/[Gralloc](  129): refresh rate = 60.12 Hz
D/libEGL  (  129): loaded /system/lib/egl/libEGL_mali.so
D/libEGL  (  129): loaded /system/lib/egl/libGLESv1_CM_mali.so
D/libEGL  (  129): loaded /system/lib/egl/libGLESv2_mali.so
E/SurfaceFlinger(  129): couldn't find an EGLConfig matching the screen format
W/SurfaceFlinger(  129): ro.sf.lcd_density not defined, using 160 dpi by default.
I/SurfaceFlinger(  129): EGL informations:
I/SurfaceFlinger(  129): # of configs : 21
I/SurfaceFlinger(  129): vendor    : Android
I/SurfaceFlinger(  129): version   : 1.4 Android META-EGL
I/SurfaceFlinger(  129): extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer
I/SurfaceFlinger(  129): Client API: OpenGL ES
I/SurfaceFlinger(  129): EGLSurface: 5-6-5-0, config=0x0
I/SurfaceFlinger(  129): OpenGL informations:
I/SurfaceFlinger(  129): vendor    : ARM
I/SurfaceFlinger(  129): renderer  : Mali-400 MP
I/SurfaceFlinger(  129): version   : OpenGL ES-CM 1.1
I/SurfaceFlinger(  129): extensions: GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_single_precision GL_OES_matrix_get GL_OES_read_format GL_OES_compressed_paletted_texture GL_OES_point_size_array GL_OES_point_sprite GL_OES_texture_npot GL_OES_query_matrix GL_OES_matrix_palette GL_OES_extended_matrix_palette GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image GL_OES_draw_texture GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_OES_framebuffer_object GL_OES_stencil8 GL_OES_depth24 GL_ARM_rgba8 GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_rgb8_rgba8 GL_EXT_multisampled_render_to_texture GL_OES_texture_cube_map GL_EXT_discard_framebuffer GL_EXT_robustness
I/SurfaceFlinger(  129): GL_MAX_TEXTURE_SIZE = 4096
I/SurfaceFlinger(  129): GL_MAX_VIEWPORT_DIMS = 4096 x 4096
I/SurfaceFlinger(  129): flags = 00000000
D/display (  129): ####disp_init, mode:0,out_type:1,tv_mode:0,app_width:1024,app_height:768
D/DisplayDispatcher(  129): display dispatcher enabled

... y aquí se detiene logcat - no hay más mensajes.

Así, el error principal parece ser "El subsistema de pantalla no se ha podido inicializar", y explica la pantalla negra; sin embargo, no puedo decirlo realmente:

  • ¿Es una causa de hardware: tal vez durante la sustitución de la batería, desconecté accidentalmente algún pin de la pantalla, por lo que aunque se muestren las pantallas de inicio, hay un error más tarde cuando se inicializa el funcionamiento normal?
  • Hay muy pocos recursos en línea que mencionan este error, y creo que llegué a un registro de chat de IRC, donde se recomendó un restablecimiento de fábrica para un error como este. Me imagino, que tal vez hay un ID en la batería de los tipos, y ya que ahora se cambia de la original, el sistema operativo ve que como un error, y se niega a continuar. Obviamente, NO quiero hacer un restablecimiento de fábrica - porque entonces, pierdo todos los datos del dispositivo (haría un adb pero eso suele generar un aviso en el dispositivo, y como la pantalla no funciona, no podría haberlo permitido aunque el sistema arrancara en un estado en el que hubiera mostrado el aviso)

Así que mis preguntas son:

  • ¿Alguien sabe qué es más probable como causa de ump_open error: ¿desconexión de cables de hardware, o tal vez diferente ID de la batería?
  • ¿Es realista esperar que el restablecimiento de fábrica resuelva este problema?
  • Si tengo que hacer un restablecimiento de fábrica, ¿hay alguna manera de hacer una copia de seguridad de este dispositivo puramente desde adb (pero sin utilizar ningún elemento de la interfaz gráfica de usuario en el dispositivo de destino)?
  • Logcat dice: "El subsistema de visualización no se ha podido inicializar. compruebe los registros". - ¿hay otros registros además de logcat que pueda comprobar; y si es así, cuáles son?
  • ¿Hay algo más que pueda probar para que esta tablet arranque completamente?

1 votos

¿Funcionaba completamente la tablet antes de la sustitución de la batería? En cuanto a la check logs entrada Yo asumiría que esto es una salida genérica de un controlador desarrollado para Linux. Podría no ser aplicable en Android en absoluto.

0 votos

Muchas gracias @Robert - la tablet funcionaba antes a pleno rendimiento; sin embargo, había estado apagada durante varios meses antes del intento de sustitución de la batería de hoy. Gracias por el check logs comentario, eso tiene sentido.

1voto

sdaau Puntos 131

Bueno, eso fue un doozy para mí ...

En primer lugar, me di cuenta de que el estado anterior de esta tablet no funcionaba del todo: la antigua batería acabó descargándose por completo; después, al enchufar el cargador sólo aparecía la pantalla de inicio de "carga de la batería", pero el dispositivo se negaba a arrancar; y en ese momento se guardó, hasta ahora.

De todos modos: en primer lugar, como se documenta aquí ¿Por qué Android lista algunos archivos que no son accesibles (error de E/S)? Descubrí que había algunos archivos del sistema que causaban un error de E/S. Eso me hizo pensar que hay una posible corrupción del /system partición flash - en cuyo caso, un restablecimiento de fábrica sí ayudaría.

En primer lugar, los montajes visibles en este momento a través de adb (en este momento, todavía lo ejecuto desde una carpeta bajo MSYS2 bash, por eso las barras inclinadas dobles) eran:

root@android:/ # mount
mount
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
/dev/block/nandd /system ext4 rw,nodev,noatime,user_xattr,barrier=0,data=ordered 0 0

Genial, así que ahora sabemos nandd es el /system partición. Comprobemos todos los dispositivos de bloque:

root@android:/ # ls /dev/block
loop0
loop1
loop2
loop3
loop4
loop5
loop6
loop7
nanda
nandb
nandc
nandd
nande
nandf
nandg
nandh
nandi
nandj
ram0
ram1
vold

( vold es un antiguo init de Android, que sólo aparece, al parecer, cuando hay un adb conexión - no cuando está en recuperación).

Así que pensé que debía intentar hacer una copia de seguridad, y comprobar de alguna manera si había corrupción; primero probé esto para hacer una copia de seguridad:

$ ./adb.exe backup -apk -shared -all -f /c/BACKUP/2021_06_26_DENVER_TAC_97032.ab
WARNING: adb backup is deprecated and may be removed in a future release
Now unlock your device and confirm the backup operation...

... pero esto necesita una GUI activa para la confirmación - y mi pantalla aquí no arranca... así que no hay dados.

Entonces encontré https://github.com/TissueFluid/yaffs2-recovery lo que me hizo intentarlo:

$ ./adb shell 'nandread -d /dev/block/nandd -f /dev/tty' > nandd.bin

El problema es que realmente no tengo espacio de disco de sobra en este momento, así que traté de redirigir a /dev/stdout (para poder guardar el stream en el PC) pero no existía; y finalmente intenté /dev/tty - pero todo lo que obtuve fueron algunos mensajes de error de texto en el archivo de salida: " failed get mtd info for /dev/block/nandd, Not a typewriter ".

Ok, así que pensé, déjame comprobar si hay corrupción:

root@android:/ # e2fsck /dev/block/nandd
e2fsck /dev/block/nandd
e2fsck 1.41.11 (14-Mar-2010)
e2fsck: Device or resource busy while trying to open /dev/block/nandd
Filesystem mounted or opened exclusively by another program?

root@android:/ # umount /system
umount /system
failed: Device or resource busy

Eh sí, realmente no se puede desmontar el /system partición, cuando es el sistema en uso ...

Entonces encontré esto: https://superuser.com/questions/401217/how-to-check-Root-partition-with-fsck - ninguno si es realmente aplicable aquí.

Entonces cometí un grave error: descubrí que hay un programa directiotest - así que pensé, ¿qué podría salir mal, es una "prueba" de dispositivos de bloque? BAD error:

root@android:/ # /system/xbin/directiotest
/system/xbin/directiotest
Usage: directiotest blkdev_path

1|root@android:/ # /system/xbin/directiotest /dev/block/nandd
/system/xbin/directiotest /dev/block/nandd
Starting test
Testing area 8192/8192 (100.00% complete)
Test complete

root@android:/ # ls -la /system/xbin
ls -la /system/xbin

Ouch ...

$ ./adb logcat
- exec '/system/bin/sh' failed: No such file or directory (2) -

Oops ... el todo /system el sistema de archivos ha desaparecido ¡! Mirando la fuente después https://Android.googlesource.com/platform/system/extras/+/master/tests/directiotest/directiotest.c - resulta que "prueba" escribiendo bytes en la memoria Flash, y luego leyéndolos; ¡lo que (ahora) obviamente hace que se borre todo el contenido!

Oh, maldición; sólo queda la recuperación para intentar: apagar la tablet; Power + Vol Up para llegar a la salpicadura del "droide muerto"; y el Power + Vol Up + Vol Down (o algún otro combo) - y podría ver eso /sdcard los archivos seguían vivos y en la lista. Vaya, más vale que lo respalde... pero si no pude hacerlo con adb backup antes, ahora sería aún menos capaz de utilizarlo...

Entonces encontré https://stackoverflow.com/questions/19908641/how-do-you-use-force-adb-to-backup-without-user-confirmation que sugiere:

sudo adb shell dd if=/dev/block/bootdevice/by-name/boot > boot.bin

Bueno, no tenía dd antes, y ahora ni siquiera tengo shell - así que no...

Es curioso, como se sugiere en https://stackoverflow.com/questions/10050925/how-do-i-adb-pull-all-files-of-a-folder-present-in-sd-card -- Todavía podría usar adb pull para copiar archivos de la tarjeta sd; pero:

$ ../adb pull '//sdcard'
adb: error: cannot create '.\sdcard\Android\data\net.nurik.roman.muzei\cache\artcache\net.nurik.roman.muzei_com.google.android.apps.muzei.gallery.GalleryArtSource\file__external_images_media_16730_a40e97f6903cd2217b225c5fcec4cfcc_6d89a17d2a7ee168c95d93662a817314': Not a directory
pull: building file list...

Por lo tanto, este puede han funcionado - desgraciadamente, adb rompe el proceso al primer error, y aparentemente también /sdcard se corrompió...

Para solucionar esto, La extracción de ADB se detiene tras el primer error sugiere tar - pero sí, no tengo tar más, ya que residía en el borrado /system ... También encontré una sugerencia para:

$ ../adb-sync --adb=../adb --reverse //sdcard/ .
INFO:root:Sync: local b'.', remote b'//sdcard/'
ERROR:root:Device not connected or not working.

Sí, esto también utiliza /system comandos, que ahora se borran...

Y por último, este https://stackoverflow.com/questions/29442630/copy-full-disk-image-from-Android-to-computer ayudado:

Como se dice en el comentario, adb pull /dev/block/mmcblk0 mmcblk0.img me ha funcionado

Muy bien:

$ ../adb pull //dev/block/nanda nanda.img
//dev/block/nanda: 1 file pulled, 0 skipped. 5.9 MB/s (16777216 bytes in 2.702s)
...
$ ../adb pull //dev/block/nandj nandj.img
//dev/block/nandj: 1 file pulled, 0 skipped. 4.3 MB/s (5519704064 bytes in 1237.721s)

Sí, tengo todo nand dispositivos ahora; comprobación rápida:

$ for ix in *.img; do echo "$(du -hs $ix); $(file $ix)"; done
16M     nanda.img; nanda.img: , code offset 0x0+3, OEM-ID "        ", sectors/cluster 4, root entries 256, sectors 32768 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 32, sectors/track 0, dos < 4.0 BootSector (0x0), FAT (16 bit)
16M     nandb.img; nandb.img: data
32M     nandc.img; nandc.img: Android bootimg, kernel (0x40008000), ramdisk (0x41000000), page size: 2048, cmdline (console=ttyS0,115200 rw init=/init loglevel=8)
512M    nandd.img; nandd.img: data
1.2G    nande.img; nande.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-ffffabf4-655f-ffffbf67-946fc0f9fffff25b (extents) (large files)
16M     nandf.img; nandf.img: data
32M     nandg.img; nandg.img: Android bootimg, kernel (0x40008000), ramdisk (0x41000000), page size: 2048, cmdline (console=ttyS0,115200 rw init=/init loglevel=8)
256M    nandi.img; nandi.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-ffffabf4-655f-ffffbf67-946fc0f9fffff25b (extents) (large files)
5.2G    nandj.img; nandj.img: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "android ", sectors/cluster 8, sectors/track 63, heads 64, sectors 10776527 (volumes > 32 MB), FAT (32 bit), sectors/FAT 10504, serial number 0x7d690be0, label: "CRANE      "

Bonito, así que aparentemente nandj aquí está /sdcard ... Ahora puedo fsck los archivos de imagen en su lugar, pero tengo que arrancar en Linux para eso ...


Bien, entonces - según https://askubuntu.com/questions/1147586/identifying-the-file-system-of-an-img-file-and-mount-it Resulta que las imágenes que son Android bootimg son montables como sysfs:

$ mkdir /tmp/nandc
$ sudo mount -t sysfs -o loop nandc.img /tmp/nandc
$ ls /tmp/nandc
block  class  devices   fs          kernel  power
bus    dev    firmware  hypervisor  module

$ mkdir /tmp/nandg
$ sudo mount -t sysfs -o loop nandg.img /tmp/nandg
$ ls /tmp/nandg
block  class  devices   fs          kernel  power
bus    dev    firmware  hypervisor  module

Sin embargo, como sysfs es es un pseudo sistema de archivos proporcionado por el núcleo de Linux Parece que no hay fsck para ello. Por lo tanto, sólo podemos hacer una comprobación del sistema de archivos en las particiones ext4 y DOS.

$ e2fsck -p -f nande.img
nande.img: Directory inode 61534, block #0, offset 0: directory corrupted

nande.img: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
    (i.e., without -a or -p options)

$ e2fsck -f nande.img
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 61534, block #0, offset 0: directory corrupted
Salvage<y>? 
...

$ e2fsck -y -f nande.img
...
Free inodes count wrong (71634, counted=71639).
Fix? yes

nande.img: ***** FILE SYSTEM WAS MODIFIED *****
nande.img: 5161/76800 files (4.9% non-contiguous), 204247/307200 blocks

$ e2fsck -f nande.img
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
nande.img: 5161/76800 files (4.9% non-contiguous), 204247/307200 blocks

$ e2fsck -y -f nandi.img 
...
nandi.img: ***** FILE SYSTEM WAS MODIFIED *****
nandi.img: 11/16384 files (0.0% non-contiguous), 2089/65536 blocks

$ e2fsck -f nandi.img 
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
nandi.img: 11/16384 files (0.0% non-contiguous), 2089/65536 blocks

$ fsck.vfat nanda.img
fsck.fat 4.1 (2017-01-24)
nanda.img: 44 files, 4188/8171 clusters

...
  Bad short file name (ö2UF.pAñ).
1) Drop file
2) Rename file
3) Auto-rename
4) Keep it
? 3
...
Orphaned long file name part "img-28773653"
1: Delete.
2: Leave it.
? 2
Reclaimed 98484 unused clusters (403390464 bytes).
Free cluster summary wrong (321342 vs. really 419828)
1) Correct
2) Don't correct
? 1
Perform changes ? (y/n) y
nandj.img: 2483 files, 924607/1344435 clusters

Por lo tanto, un poco de corrupción - por desgracia, fsck repetido de nandj no parece borrar los errores ...

A pesar de todo, tengo tan buena copia de seguridad nand como puedo ahora, así que puedo tratar de "borrar los datos / restablecimiento de fábrica" de la recuperación del sistema Android <3e> menú ... Por desgracia, el resultado final es ahora:

-- Wiping data...
Formatting /data...
Formatting /cache...
E:failed to mount /system (Invalid argument)
Data wipe complete.

Eh, así que aparentemente no puedes recuperar /system en este dispositivo ...

Así que mi mejor apuesta ahora, es encontrar de alguna manera el firmware original para restaurar.

En resumen: la vieja batería, al fallar, probablemente causó alguna corrupción de la flash -- que se reveló por primera vez al instalar la nueva batería. A pesar de mi error de borrar /system Para empezar, estaba corrupto, y el restablecimiento de fábrica no habría servido de nada aunque no hubiera cometido el error de borrarlo.

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X