Puede acercarse, pero no puede evitar ese comportamiento a menos que haya un entorno desconocido para usted o que el dispositivo esté rooteado. No importa lo que pase automatización que usas, el brillo se pondría al máximo cuando el nivel de la batería alcance el 100% y en cuestión de unos pocos milisegundos, se revertiría a lo que quieras que sea. Mi solución se encarga de ese problema. Originalmente publicado aquí .

El archivo llamado max_brightness un archivo bajo /sys por lo tanto, una parte del núcleo de Linux y directamente administrado por él, parece ser la clave de la solución. Encontré que establecer el límite de brillo en ese archivo es una de las mejores maneras de abordar el problema.

Me di cuenta de que una vez que se establece el máximo brillo personalizado, ni Android ni una aplicación podía establecer el brillo más allá de ese nivel personalizado a menos que cambiaran el contenido de ese archivo, lo que a menudo una aplicación no tiene razón de ser y ninguna de ellas tampoco cambió. Además, el archivo es propiedad de Root y forma parte del grupo Root, por lo que cualquier aplicación o incluso system_server requeriría el privilegio de Root para hacer cambios en ese archivo.

Encontrar ese archivo es un poco difícil. En mi dispositivo MTK con Android 4.2, ese archivo parece estar bajo /sys/devices/platform/leds-mt65xx/leds/lcd-backlight/ .

En mi dispositivo Qualcomm con Android 5.0.2 y superior, el archivo parecía estar en /sys/devices/mdp.0/qcom,mdss_fb_primary.168/leds/lcd-backlight/ .

Asumo que la mejor manera de encontrar ese archivo es ejecutar una consulta de búsqueda (setup adb para eso), como:

_{(Requiere <a href="https://play.google.com/store/apps/details?id=stericson.busybox" rel="nofollow">busybox </a>)}

adb shell su -c 'find /sys/ -type f -iname "max_brightness"'

En mi dispositivo Qualcomm, la salida que da es:

/sys/devices/f9924000.i2c/i2c-2/2-0068/leds/red/max\_brightness
/sys/devices/f9924000.i2c/i2c-2/2-0068/leds/blue/max\_brightness
/sys/devices/f9924000.i2c/i2c-2/2-0068/leds/green/max\_brightness
**/sys/devices/mdp.0/qcom,mdss\_fb\_primary.168/leds/lcd-backlight**/max\_brightness
/sys/devices/qcom,camera-led-flash.81/leds/torch-light/max\_brightness
/sys/devices/msm\_sdcc.1/leds/mmc0::/max\_brightness
/sys/devices/msm\_sdcc.2/leds/mmc1::/max\_brightness
/sys/devices/01-qcom,leds-d300/leds/led:flash\_torch/max\_brightness
/sys/devices/01-qcom,leds-d300/leds/led:flash\_0/max\_brightness
/sys/devices/01-qcom,leds-d300/leds/led:flash\_1/max\_brightness
/sys/devices/01-qcom,leds-e200/leds/kpdbl-lut-2/max\_brightness
/sys/devices/01-qcom,leds-e200/leds/kpdbl-pwm-3/max\_brightness
/sys/devices/01-qcom,leds-e200/leds/kpdbl-pwm-4/max\_brightness
/sys/devices/01-qcom,leds-e200/leds/button-backlight/max\_brightness

El lugar donde lcd-backlight es mencionado fue el único que tenía sentido para mí y así es como encontré el archivo en mi dispositivo. No te preocupes por preguntar por los demás. Intenté cambiar el brillo de la pantalla y busqué los cambios en el archivo llamado brightness (también situado debajo de esos lugares). Ninguno de ellos reflejaba la salida correcta, excepto el de /sys/devices/mdp.0/qcom,mdss_fb_primary.168/leds/lcd-backlight .

Sólo para demostración, intente establecer un límite en max_brightness

adb shell su -c 'echo LIMIT > PATH_TO_MAX_BRIGHTNESS'   # in my case PATH_TO_MAX_BRIGHTNESS is /sys/devices/mdp.0/qcom,mdss_fb_primary.168/leds/lcd-backlight/ and set LIMIT to a value less than 30 (not limited to). 

Ahora intente maximizar el brillo usando el deslizador de brillo o una aplicación de terceros y notará que el brillo de su pantalla no excede de un cierto punto incluso cuando el deslizador o la configuración de la aplicación parece estar al máximo. El brillo para ese "cierto punto" sería ciertamente menor que el predeterminado al que estás acostumbrado.

Nota que el valor máximo en max_brightness se encuentra a menudo en 255 y el brillo oscila entre 0-255. A menudo, no siempre es cierto, es decir. Y no teme poner el límite en 0. Haría que la pantalla no se encendiera hasta que revierta los cambios o reinicie el dispositivo.

Encuentra un límite que no te perturbe mientras duermes.

Automatización

Para automatización usar cualquier aplicación de automatización que pueda ejecutar un comando con privilegios de root y cuando se cumpla el contexto de su disparador preferido. Recomiendo un disparador basado en el tiempo.

Algunos ejemplos de trabajo:

• En Tasker establecer un perfil con su contexto preferido, crear una tarea y usar la acción: Código → Ejecutar Shell:

  • Comando: echo LIMIT > PATH_TO_MAX_BRIGHTNESS
  • marque Usar root

• En MacroDroid configura tu disparador preferido y para la acción, instala Configuración segura , elegirlo → Acciones → Ejecutar el comando:

  • Comando: echo LIMIT > PATH_TO_MAX_BRIGHTNESS
  • marque Usar root

• En Automatizar como parte de su flujo, al establecer una acción para su disparador, seleccione El superusuario del comando Shell en las aplicaciones y hacer:

  • Línea de mando: echo LIMIT > PATH_TO_MAX_BRIGHTNESS

  Asegúrate de instalar todos los permisos que requiere el flujo.

• En DroidAutomation , configure su disparador y bajo tarea, seleccione root → Ejecute una línea de comando y escriba: echo LIMIT > PATH_TO_MAX_BRIGHTNESS

Como habrás adivinado, tendrías que configurar dos perfiles para cada aplicación. Uno para establecer un límite y el otro para establecer el brillo máximo al valor predeterminado al que estás acostumbrado.

Me gustaría que mantener esto en consideración (aunque al principio se le insinuó) que el uso de un disparador de batería al 100% anularía el propósito de esta respuesta, que es anular los cambios que Android quiere hacer. Por ejemplo, si configuras el LÍMITE a 0 cada vez que la batería llegue al 100%, lo que sucederá es que tu Android encenderá la pantalla al máximo como de costumbre y en pocos milisegundos (lees correctamente) tu aplicación de automatización se ejecutará y establecerá el límite. Tu sueño puede ser interrumpido en esos milisegundos.

La solución es ajustar el nivel de la batería a 99 o menos para una carga completa.

Dicho esto, no me sorprendería si evitasen rootear considerando que el mayor compromiso que harían al usar una respuesta con un enfoque no rooteado es el de no contabilizar esos molestos, sino sólo milisegundos.