I have android 8 from nxp and using it on sabresd board.
I am trying to change dpi settings through setprop settings
So I have put this iside init.${hardware}.rc on boot event
# Set the density to 160dpi, default 128dpi is not good
# Set the density to 128 dpi for 480x800, 7 inch.
setprop ro.sf.lcd_density 128
The device works fine and if I do this
wm density
Physical density:128
Now I put this dpi setting in kernel command line
androidboot.sf.lcd_density=128
but I do not see device to be in 128 dpi setting. Also
wm density
Physical density:160
Now this baffles me.Who gave 160dpi settings?
How putting setprop in init.$hardware.rc affects the display but not in kernel command line.
Who really processes setprop.
I tried putting prints like this
on boot
exec /system/bin/echo "Trigger test E"
I saw nothing, so does that mean boot event never happened?
In android framework there is a file called
display file
that contains default dpi if none is specified.
This file have this setting,
public static final int DENSITY_MEDIUM = 160;
Which is used if no dpi is specified.
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 have a KeDei 3.5 ich SPI TFT LCD Display. I attached to Raspberry Pi with Android Things Image. When I boot the RPi, nothing is shown, only displays a black screen. The display is getting powered up, and I can differentiate between it's on and off state. But when I try remote display (followed steps from this post), I can see the display properly.
Logcat output which I think is related to display:
mBaseDisplayInfo=DisplayInfo{"Built-in Screen", uniqueId "local:0", app 640 x 480, real 640 x 480, largest app 640 x 480, smallest app 640 x 480,mode 1, defaultMode 1, modes [{id=1, width=640, height=480,fps=60.000004}], colorMode 0, supportedColorModes [0], hdrCapabilities android.view.Display$HdrCapabilities#1d6308, rotation 0, density 240 (0.0 x 0.0) dpi, layerStack 0, appVsyncOff 1000000, presDeadline 16666666, type BUILT_IN, state ON, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS, removeMode 0}
I tried latest Raspbian Image and dev preview 0.4.1 as mentioned here. Tried with HDMI config given in the same link. Nothing works except the rpi_35_v6.3_ubuntu_mate_15_kedei image from KeDei vendor.
Display Specs:
480x320 16bit/18bit
version 6.3 2016/11/1
Android Things:
OS: 0.6.1-devpreview
Build: OIM1.171126.016
Empty Bundle
According Hardware Platforms description, Raspberry Pi with Android Things support Display only via HDMI or DSI interfaces, not via SPI, and there is no built in drivers for it - your KeDei 3.5 ich SPI TFTLCD Display will not work. You can use that display only from your application via SPI commands (something like custom driver), but not from Android Things system.
I have an android app, this application connect to server to download images, but this images has more than one copy, first copy 1600 * 1080 pixel and the second is 800 * 540 ...
so the device should send tag to server to download the good images for this device
I used many ways to check the device memory or density but the results was not clear enough to make a decision, here some code I used:
float density = getResources().getDisplayMetrics().density;
long mem = Runtime.getRuntime().freeMemory();
long heap = Debug.getNativeHeapAllocatedSize();
the results was for 3 devices like this:
samsumg tab 10 inch = 1.0 , 745464 , 3249552 byte
china tab 7 inch = 1.0 , 559944 , 2789016 byte
htc moble 3.4 inch = 1.5 , 1760904 , 8942736 byte
as the result showed the htc is the better but it was not because I can't view the highest resolution on it, but on the other devices it was very good
the error msg:
java.lang.OutOfMemoryError: bitmap size exceeds VM budget(Heap Size=7687KB, Allocated=3356KB, Bitmap Size=25092KB)
Any help in this issue ?
Your decision should depend on two factors:
Screen density.
Screen Size.
In your case you had received hdpi drawables on htc, but it's small device, so it's not required to show large image with more details on small device.
for more information for loading large bitmaps efficiently:
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html
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 need a way to detect device screen size and density with adb.
If there is no solution, where can I get the complete list of all existing android device with their screen size and density ?
You can also access the WindowManager through ADB:
$ adb shell wm
usage: wm [subcommand] [options]
wm size [reset|WxH]
wm density [reset|DENSITY]
wm overscan [reset|LEFT,TOP,RIGHT,BOTTOM]
To get the screen resolution:
$ adb shell wm size
Physical size: 2880x1600
To get the screen the density:
$ adb shell wm density
Physical density: 320
You can also override the density by adding the new density:
$ adb shell wm density 160
LCD density is in the build.prop:
adb shell getprop ro.sf.lcd_density
And the resolution is availble in the dumpsys of the input activity:
# windows
adb shell dumpsys window | find "DisplayWidth"
# linux
adb shell dumpsys window | grep DisplayWidth
It works on all the devices I've tested with (2.2, 2.3.3, 2.3.4, 4.0.3; Acer Liquid E, HTC Wildfire S, HTC Incredible S, Motorola Atrix 4G, Samsung Galaxy Note, Samsung Galaxy Nexus), as well as the emulator, although the emulator's outputs are too clean to serve as a good example for parsing.
Using dumpsys
dumpsys window displays
shows something like this:
Display: mDisplayId=0
init=1080x1920 480dpi cur=1080x1920 app=1080x1920 rng=1080x1005-1920x1845
layoutNeeded=false
another way:
dumpsys display
also shows some interesting stuff like:
mDefaultViewport=DisplayViewport{valid=true, displayId=0, orientation=0, logicalFrame=Rect(0, 0 - 1080, 1920), physicalFrame=Rect(0, 0 - 1080, 1920), deviceWidth=1080, deviceHeight=1920}
and last but not least:
dumpsys power
will display something like
Electron Beam State:
mPrepared=false
mMode=2
mDisplayLayerStack=0
mDisplayWidth=1080
mDisplayHeight=1920
mSurfaceVisible=false
mSurfaceAlpha=0.0
that you could easily use to grep for mDisplayWidth and mDisplayHeight
To get required info from ADB, the following command executed from the command line will return a lot of useful properties about the connected devices
> adb shell getprop
To filter through these properties
on Unix use grep like
> adb shell getprop | grep density
on Windows use find like
> adb shell getprop | findstr "density"
Returned value looks like
[ro.sf.lcd_density]: [240]
for screen size put display instead of density
Work is Good:
dumpsys window | grep Display
return: Display: init=320x480 cur=320x480 app=320x480 rng=320x295-480x455
ANDROID:/ # dumpsys window | grep mGlobalConfiguration
mGlobalConfiguration={1.0 ?mcc?mnc [en_US] ldltr sw720dp w1920dp h532dp 160dpi
So resolution is 1920x720
You can get screen dimensions with this code:
public int getScreenHeight() {
return getDisplay().getHeight();
}
private Display getDisplay() {
return ((WindowManager) getContext().getSystemService(
Context.WINDOW_SERVICE)).getDefaultDisplay();
}
public int getScreenWidth() {
return getDisplay().getWidth();
}
Once you have the Display in the code above you can use DisplayMetrics to get the density. DisplayMetrics will also give you absolute display with and height.
Look at the output of adb shell dumpsys. The screen size shows up there several times, along with lots of other information.
... although now I'm in the office, while it works on my phone, it's absent from the Galaxy tablet. Darn.
If you need to get the current status of range of Android device available in the market with it Screen Sizes and Densities Click here
This data is based on the number of Android devices that have accessed Android Market within a 7-day period ending on the data collection date