My phone's display backlight even after setting to minimum hurts me in dark. I checked the valid range of values for the file /sys/class/leds/lcd-backlight/brightness and found it takes 0 - 255 . 0 is display off, 1 is minimum brightness, and 255 is maximum brightness.
The android system display settings when set to minimum sets the sys file value to 5 which hurts my eyes in dark. I echoed the value 1 from root terminal and it sets brighness to lowest value that makes my eyes comfortable in dark.
The sys file is owned by user system and group system and its permissions are -rw-r--r-- .
I need my app to write to /sys/class/leds/lcd-backlight/brightness to set the display brightness to a very minimum value. If I use su command in app, I can modify the file. But I want to do the same without superuser permission. Is there some sort of permission that allows me to modify the file?
What are the possible ways to modify the /sys file without root permissions?
You don't need user permissions to change the screen's brightness. Just do this:
WindowManager.LayoutParams
layoutParams = getWindow().getAttributes();
layoutParams.screenBrightness = BackLightValue;
getWindow().setAttributes(layoutParams);
The variable BackLightValue is used to set the brightness to auto but you can change it to whatever you need
Related
Many Android devices with AMOLED screens display all images with oversaturated colors by default. E.g. Samsung Galaxy phones have the "Adaptive" screen mode, which forces windows of all apps to be displayed as if they were rendered in the native screen color space, which is wider than Display-P3.
OTOH, not all such devices support EGL_EXT_gl_colorspace_display_p3, regardless of screen mode, so I can't be sure whether the device my app is running on even has a wide-gamut screen, even less determine whether this mode is the default.
So, how can I actually determine whether current screen mode is sRGB or some wide-gamut mode? I'm targeting one specific device model, Samsung Galaxy A320F/DS (AKA "A3 (2017)"), so platform-specific ways are also OK.
There are several layers where colors can be manipulated.
SurfaceFlinger. This component is common to all Android systems. One can pass a custom color matrix to it (see the source code of the handler of this request) via e.g. the following command executed as the root user:
service call SurfaceFlinger 1015 i32 1 \
f 0 f 0 f 1 f 0 \
f 0 f 1 f 0 f 0 \
f 1 f 0 f 0 f 0 \
f 0 f 0 f 0 f 1
The above example command sets a matrix that will, acting on RGBA vectors, swap red and blue channels. To reset the custom matrix to default (identity) you can simply do
service call SurfaceFlinger 1015 i32 0
You might be able to do all this from a Java/JNI app without root privileges, simply asking for some permission, I didn't research this.
mDNIe, which stands for mobile Digital Natural Image engine. It's a Samsung-specific system that acts on a lower level than SurfaceFlinger. Namely, it affects Always On Display, on which SurfaceFlinger's custom color matrix doesn't have any effect.
Current screen mode can be seen in the /sys/class/mdnie/mdnie/mode file, which appears to have the following mapping of values on Galaxy A320F/DS:
0 — AMOLED cinema (apparently aims at Display-P3),
1 — AMOLED photo (apparently aims at Adobe RGB),
2 — Basic (aims at sRGB),
3 — (don't know its purpose, but the value is accepted if written to mode)
4 — Adaptive display (the widest, apparently native screen color space).
5 — (don't know its purpose, but the value is accepted if written to mode)
Moreover, the colors are also affected by the Cool — Warm slider as well as Advanced options RGB per-channel adjustments. Changes to the former are somehow reflected in mdnie_ldu and sensorRGB files in the same directory, while the latter directly corresponds to whiteRGB file.
Also, Blue light filter feature state is reflected in the night_mode file (it also influences mdnie_ldu and sensorRGB files mentioned above).
Of the files described above, only mode is readable to a non-root user on SM-A320F/DS. On SM-G950FD (AKA "S8") nothing is accessible without root.
I found some info on the web:
echo 1 /sys/devices/platform/flashlight.0/leds/flashlight/brightness
But on my Nexus 7 (flashed an AOSP), I couldn't find that directory.
Any idea about which file should I write to? Is this doable?
After ls /sys/devices/platform, I got:
LID
alarm
arm-pmu.0
bcm4330_rfkill
bcmdhd_wlan.1
bluesleep
fiq_debugger.0
fsl-tegra-udc
gpio-keys.0
grouper_misc
leds-gpio
oprofile-perf.0
power
power.0
pwm-backlight
ram_console
reg-dummy
reg-fixed-voltage.1
reg-fixed-voltage.10
reg-fixed-voltage.11
reg-fixed-voltage.2
reg-fixed-voltage.3
reg-fixed-voltage.4
reg-fixed-voltage.6
reg-fixed-voltage.8
regulatory.0
sdhci-tegra.2
sdhci-tegra.3
serial8250
snd-soc-dummy
spdif-dit.0
spdif-dit.1
spi_tegra.0
spi_tegra.3
tegra-ehci.1
tegra-i2c.0
tegra-i2c.1
tegra-i2c.2
tegra-i2c.3
tegra-i2c.4
tegra-nvmap
tegra-otg
tegra-pcm-audio
tegra-se
tegra-snd-rt5640.0
tegra30-ahub
tegra30-dam.0
tegra30-dam.1
tegra30-dam.2
tegra30-hda
tegra30-i2s.1
tegra30-i2s.3
tegra30-i2s.4
tegra30-spdif
tegra_camera
tegra_pwm.0
tegra_rtc
tegra_smmu
tegra_uart.1
tegra_uart.2
tegra_uart.3
tegra_uart.4
tegra_wdt
uevent
There is a new binary shipping with Android Jellybean 4.2, which can be used to directly read/write to the system settings provider, accessible via command line.
For example: in order to increase brightness of the screen, use below command:
adb shell settings put system screen_brightness 200
Read more about SCREEN_BRIGHTNESS Note that the range of values is [0 - 255]
The range of values is not necessarily from 0 - 255. On my OnePlus for example
it ranges from 0-2047. If you want to know yours just set the brightness slider to max and
then type: adb shell settings get system screen_brightness.
You should use the pwm-backlight!
You can use this adb command to set screen brightness
adb shell settings put system screen_brightness 255
and if your device has auto brightness setting then use this command first
adb shell settings put system screen_brightness_mode 0
This did not work for the latest Nexus 7 (2013) for me. But this answer explains the way to find what you are looking for on any version: https://stackoverflow.com/a/13492336
However we need to note that in order to change any of this you need to have root access.
I want to put my phone in dim mode using my application. It seems phone's home screen will be in deem mode. If I going to use Power Manager class then it will drain battery. How can I do this then? Can any one give some sample code?
In my case I just update the Android Default Settings,
android.provider.Settings.System.putInt(cr,android.provider.Settings.System.SCREEN_BRIGHTNESS, 1);
Note: here 1 is value for dim (low) (values 0 t0 250) , and cr is ContentResolver's object
For this you have to mentioned permission in manifest file,
<uses-permission android:name="android.permission.WRITE_SETTINGS"/>
Inside my app, I need a way to turn off the lights on the standard Android phone keys (Home, Menu, Back, and Search) - how can I do this programmatically?
According to this page, the hardware key backlights can be controlled by writing to a specific file in the filesystem with superuser privileges (i.e. phone must be "rooted"):
Q: How can I control the keyboard
backlight?
A: The keyboard backlight can be
controlled via
/sys/class/leds/keyboard-backlight/brightness.
It appears that it's a simple on-off
control (echoing '0' turns it off,
echoing '1' or higher turns it on).
For some reason, the default system
backlight control stuff seems to set
this to "83", but I don't know why. I
can't seem to see any difference
between 83 and any other number. The
file is readable by anyone, but only
writable by root, so you'll need root
access to the phone to manipulate it
this way.
So to turn off the backlight programmatically, you could invoke exec() on the Runtime like so:
Runtime r = Runtime.getRuntime();
r.exec("echo 0 > /system/class/leds/keyboard-backlight/brightness");
Depends on what you are doing, but would probably be wise to check the result of exec() afterwards to see if a write error occurred.
Note: I tested this on my own phone and it seems to work without acting as root. However, this may not be the case on every phone, so you may have different results.
This is applicable only for the device samsung devices:
To get the BackLight sate:
int backLight = Settings.System.getInt(getContentResolver(), "button_key_light");
// if it return -1 it means that light is on
// if it return 0 the light is off
// some time it will return values like 600(1.5 sec)
if you want to put the backLight as off u can do like this
Settings.System.putInt(getApplicationContext().getContentResolver(), "button_key_light", 0);
I read that in froyo if you change vibrate settings with setVibrateSettings() it doesn't sync with SO vibrate settings. Then I found this workaround that people use with some of the functions in this link:
https://android.googlesource.com/platform/packages/apps/Settings/+/froyo-release/src/com/android/settings/SoundSettings.java
However, that source code there are two calls to:
173 boolean vibeInSilent = (Settings.System.getInt(
174 getContentResolver(),
175 Settings.System.VIBRATE_IN_SILENT,
176 1) == 1);
227 Settings.System.putInt(getContentResolver(),
228 Settings.System.VIBRATE_IN_SILENT,
229 vibeInSilent ? 1 : 0);
That are the only difference with what I try to do in my code to change vibrate setttings. But Settings.System.VIBRATE_IN_SILENT seems to be removed in 2.2, so when I change vibrate settings "normal, off, only in silent", then I go to SO audio settings and vib value is different, and if i go back to my app, vib settings are also different to what i selected before. Any ideas?
Try the following link:
http://www.kiwidoc.com/java/l/p/android/android/8/p/android.provider/c/Settings.System
From what I have tried, the setting still exist but not exposed as it used to be. It can still be set using the Settings.System.putInt(...) just specify the name "vibrate_in_silent".
I guess that someday this will no longer work so I recommend protecting your code in any way possible (check if setting exist by calling getInt first, add try-catch...)