Así que, tengo un dveice MT6739 con Android 8.1, no es A/B sin fisuras, y no es TREBLE.
He utilizado un método probado para eliminar DM-Verity. En este dispositivo estaba en el DTB, en el boot y también en las particiones del proveedor. Utilizo Magisk para hacerme Root y he eliminado e instalado un montón de /system/apps, he cambiado el audio, las animaciones de arranque, etc en el dispositivo. Incluso he cambiado los fondos y retocado el Launcher.
Sin embargo, cada vez que cambio algo en /system/build.prop el dispositivo arranca.
He probado esto con Magisk DM-verity ON/OFF sin ningún efecto. También he copiado un build.prop de mi PC y ha vuelto a funcionar bien. Así que, algo debe estar buscando el build.prop y comprobando los cambios.
Todo lo que he hecho es cambiar la propiedad ro.product.model para estar super seguro de que nada en el build.prop es incorrecto. He probado con la configuración de los permisos (644, por alguna razón son 600 (RW - - ) en el dispositivo así que probé eso también).
Hay un build.prop en la partición /vendor. He oído hablar de esto comprobando la huella digital del sistema/build.prop, pero de todas formas son diferentes en la ROM stock.
También he probado a copiar el build.prop de /system aquí para que sean idénticos.
¡¡Fresco de ideas!!
¿Alguien sabe qué está pasando aquí? Puedo literalmente cambiar todo lo que quiero en el dispositivo como días normales / preverity a excepción de la configuración build.prop.
0 votos
Tal vez tengas CRLF en lugar de LF al final de la línea (compruébalo con Notepad++)
0 votos
Como mencionó @alecxs CRLF podría ser una razón. Haga
dos2unixenbuild.prop. Compruebe también la etiqueta SELinux. Compruebe el registro del kernel ylogcatpara cualquier pista sobre la razón del bootloop.0 votos
Gracias por los comentarios. Lo intentaré, hoy he estado fuera todo el día así que lo probaré mañana. El problema es que, literalmente, sólo estoy cambiando el nombre del dispositivo o el modelo por lo que no crear un salto de línea o CR en absoluto. Estoy en un sistema W10 sin embargo, por lo que es un poco notorio para eso. ¡El problema es que si edito el build.prop de nuevo a la forma en que estaba y luego copiarlo en el dispositivo, que arranca bien!
0 votos
Una cosa que se me da muy mal es obtener los registros de un dispositivo. Hay un hilo decente en cualquier lugar que me puede ayudar a configurar Logcat en el dispositivo?
0 votos
OK, así que logcat aprendido, aquí hay una actualización. Copié el build.prop, hice 1 cambio en el nombre del dispositivo, asegurándome de no hacer ningún salto de línea, etc. Corrí el build.prop a través de DOS2UNIX. Lo reemplacé en el dispositivo, chmodded, se aseguró de magisk se estaba ejecutando y tenía verity comprobación de apagado y reinició el dispositivo con logcat corriendo en mi ventana de ADB. Todavía bootlooped. No hay logcat log a6t todos, "todavía en espera de dispositivo".
0 votos
Bien, hoy he hecho un par de cosas finales. Lo primero que hice fue volver a copiar los build.props frescos de /system y /vendor. Luego los edité cambiando 1 ajuste exactamente igual en cada uno. El dispositivo arrancó. Luego los volví a editar y volví a copiar este build.prop. El dispositivo arrancó bien. Esto realmente borra cualquier argumento para la edición de los archivos de forma incorrecta. Definitivamente hay algo que compara los valores en el build.prop en /system y no le gustan los cambios. Yo chmodded correctamente, se aseguró de DM-veridad fue manejado correctamente.
0 votos
Así que para hacer una nueva pregunta: ¿Qué podría comparar los valores en build.prop y detener el arranque si ve cambios? ¿Debe haber algún tipo de archivo o build.prop siendo comparado contra?
0 votos
Bueno, ahora he tenido la oportunidad de hacer más pruebas. Así que ahora he probado de manera concluyente que puedo cambiar un montón de propiedades en el build.prop en ambas versiones /system y /vendor. Por ejemplo, he cambiado ro.product.locale y el tono de llamada por defecto, Sin embargo, tan pronto como cambiar cualquier cosa que ver con ro.product.brand o dispositivo, que bootloops. Así que esto elimina los problemas de edición de la ecuación para siempre. Algo en alguna parte está comparando estos valores. No he podido conseguir ningún tipo de registro durante el arranque que me dé alguna pista. ¿Alguien tiene alguna idea?