[Q] ro.sf.lcd_density property doesn't work - General Questions and Answers

I got the adb root access of my Dell Venue7 3740 by following Dell's Guide (opensource.dell.com/releases/Venue_7_3740_Merrifield/developer-edition/Doc/OSS_A195.pdf)
I pulled build.prop file, but this file have not the ro.sf.lcd_density property.
So I added the ro.sf.lcd_density=160 line.
After this, I pushed build.prop and assign 644 mod to this file.
But my tablet's DPI was not changed and Quadrant Benchmark App says the DPI is 216.
What's the reason and how can I change the DPI of tablet?
Thanks,

Related

Pixel Density or Screen Resolution

I'm coming from the xperia 1 (for which i was a chef for some time) and just recently bought the sensation xe, so i'm pretty much a noob in android.
My question is .... is it possible to lower the resolution or pixel density to boost performance on the Sensation xe ?
sorry if this was asked before but i didn't find anth similar around
Yea use a dpi changer from market or prop modder app.
Or you can edit the build.prop file with root explorer or such.....
shanman-2 said:
Yea use a dpi changer from market or prop modder app.
Or you can edit the build.prop file with root explorer or such.....
Click to expand...
Click to collapse
And does it really improve performance ?
I've got problem with DPI Changer. I've set DPI to 160 and rebooted phone and now Sense is FCing all the time and I can't change DPI to default value. Is there any possible to change DPI to default value? I'cant turn on any application - there is no working launcher.
Rom is Android Revolution HD 6.2.1 (ICS 4.0.3)
easy, edit build.prop in /system
ro.sf.lcd_density=240
240 is default
But how I can get the access to build.prop? I can't open file manager. Can I change it from my PC by connecting phone with the cable?
use droid explorer, boot into recovery-->mount /system-->start droid explorer-->edit file
I think I'm doing something wrong - when I edit file in droid explorer, every time I save changes, close ando open again, the value is again 160.
copy first on desktop, make all changes and delete the file on smartphone and copy from desktop to smartphone! reboot
It's working now. Thanks, You're great
you're welcome

[q] error in lcd density

I am currently using Samsung Galaxy Y. While playing the with ROM manager,I accidentally maxed the LCD DENSITY from 120 - 240 , I THINK. When I restarted the Phone, everything is out of scale and I can't even navigate because of the resolution, I tried wiping the data, hoping to wipe the tweaks, but it failed. Please help me, I cannot use my phone.
maybe you just have to change the lcd once again..
like the original ofcourse
Adb push a modified build.prop
AOKP 4 LYF
Use adb pull
to download system/build.prop
change the value ro.sf.lcd_density
save the file
use adb push
to upload your file in system/build.prop

how to change lcd density

To change lcd density of any android phone
requirement-
Rooted Phone
Any root accessible file explorer
I suggest Root Browser
Now open File Explorer
go to root
now select system and scroll down, you will found an file named build.prop
open it by choosing like rb text editor
now scroll down and search for a line
ro.sf.lcd_density=240
240 is normal
if you want to change then relace 240 by your choice like 210, 220, 200
if there is no such line then add your self
Dont edit another build properties unless you know about it
Now after saving file
Reboot you phone and you will see that your dpi is changed :laugh: :angel:
Thanks If i helped
It is my first post

custom update.zip on unrooted phone? possible?

Hi.
I have a XOLO-ONE [non-rooted] and recently updated it via the "software update" option in the system information tab of settings. It runs Lollipop 5.0.0.
I noticed that before updating, it showed a prompt saying "no update.zip found in root of memory card, download?" I found out that you can download the update.zip from xolo's official site. It was about 30 mbs.
Now, i wonder if i can edit it's contents(updater-script, apps, etc...) and apply the update to my phone?
I repeat, it is NON-ROOTED.
The zip file contains the following folders:
META-INF
PATCH
SIG
SYSTEM
scatter.txt [FILE]
type.txt [FILE]
There is no boot.img.
Has anyone tried it? Was it successfull? If yes then please write. Your opinions would be appreciated.
Yes you can do so and its possible flashing a update.zip using stock recovery.
You can edit and change apps amd do anything but remember to update any changes you have done in zip to updater-script carefulley. And set correct permissions to them
Peace
:good::laugh::victory:
Thanks man.
Uh, can tell me how to edit the build.props file?
It is stored as a .p file.
Yes why not opsn the file as a text file in any text editor either on amdroid or on pc.
Now you can change the following things.
1-- change the android version
ro.build.version.release=4.4.2
Edit the number to version you want
2-- change the screen pixel density
ro.sf.lcd_density=200
Edit the value to nearby values only.MY DEFAULT WAS 240 AND I CHANGED IT TO 200 AND IT LOOKS NICE.
3-- change the delvic heap value
dalvik.vm.heapstartsize=10m
dalvik.vm.heapgrowthlimit=68m
delvik.vm.heapsize=256m
Edit the values but only multiply the default values by 2. If any value after multiplying is mord than the ram of your device itself then do mot change the value.
4-- add these lines to the build.prop in end for display enhansment
video.accelerate.hw=1
debug.sf.hw=1
debug.performance.tuning=1
debug.egl.hw=1
debug.composition.type=gpu
After doing so save the file normallt.
Zip the folders and flash them again.
Peace
I would do that but.....
Yes, I would do that but the problem is that the file has a .p extension.
I did some research and found that it is a patch file created by using a program called BSDIFF ( or something like that). The installer-script processes that file by comparing it's checksum and patching the data into the existing file..
Now I'm not sure if creating a custom build. Prop. P file and updating my. Zip file with it will be okay. What if I get into a boot loop? My xolo isn't rooted either.
But, I'm not the expert.
So, tell me about your opinion. Is it safe?
Thank you for your help. ( for before & in advance )
no just name it as build.prop and nothing else. itd a property file and not a .p file.
simply place the build.prop in zip file with this name only. no other name OK.
and flash it.
but if you are rooted then just edit the original file in aystem folder and savf it there only. just open and edit and reboot to see effects.
peace
Sent from my SM-G355H using XDA Free mobile app

How about a build.prop thread?

I'm used to only having one build.prop file to edit; on the SHT-AL09 there are three build.prop files - there's a system/build.prop, a vendor/build.prop, system/vendor/build.prop. The system/build.prop file is different/smaller than the other two files, one of which I presume is a vendor supplied backup.
Please excuse me if this is a stupid question - but which file(s) need to be edited to successfully implement build.prop tweaks?
Also, build.prop permissions are traditionally set to 644. However, out of the box, our build.prop permissions appear to be set to 600.
This thread can also serve as a place to share build.prop tweaks that are confirmed to not result in bootloops. Personally, I am looking forward to increasing sling velocity.
I guess build.prop tweaks are a thing of the past?
I figured out that the system/vendor/ folder is the same as the root/vendor/ folder; change a file in one and it is changed in the other as well. I have also confirmed that editing either the build.prop or default.prop files in the vendor folder affects system config. In the default.prop folder I changed the value for 'qemu.hw.mainkeys,' and afterward Nova Launcher was suddenly unable to turn the color of the text in my status bar to a dark color.
I don't plan on playing around much until we have a working recovery, but so far I have edited the following existing lines in my build.prop file:
dalvik.vm.heapsize=700m
dalvik.vm.heapstartsize=35m
dalvik.vm.heapgrowthlimit=140m
dalvik.vm.heaptargetutilization=0.72
dalvik.vm.heapmaxfree=15m
And have added the following lines:
net.tethering.noprovisioning=true
ro.config.nocheckin=1
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.hspa=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.lte=524288,1048576,2097152,524288,1048576,2097152
net.tcp.buffersize.hspda=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.evdo_b=6144,87380,1048576,6144,87380,1048576
windowsmgr.max_events_per_sec=90
I couldn't say for sure that I have seen an improvement, but I think I've seen some improvement in overall stability/multi-tasking. At least, there have been no ill effects. I am also getting better data speeds in certain parts of town via T-Mo - but that could be random or related to experimentation with my APN.
Also...VOLTE is enabled by default in the stock build.prop - unfortunately it is a known issue that Huawei phones don't get VOLTE on T-Mo (in the US) unless they have US firmware.
thref23 said:
I guess build.prop tweaks are a thing of the past?
I figured out that the system/vendor/ folder is the same as the root/vendor/ folder; change a file in one and it is changed in the other as well. I have also confirmed that editing either the build.prop or default.prop files in the vendor folder affects system config. In the default.prop folder I changed the value for 'qemu.hw.mainkeys,' and afterward Nova Launcher was suddenly unable to turn the color of the text in my status bar to a dark color.
I don't plan on playing around much until we have a working recovery, but so far I have edited the following existing lines in my build.prop file:
dalvik.vm.heapsize=700m
dalvik.vm.heapstartsize=35m
dalvik.vm.heapgrowthlimit=140m
dalvik.vm.heaptargetutilization=0.72
dalvik.vm.heapmaxfree=15m
And have added the following lines:
net.tethering.noprovisioning=true
ro.config.nocheckin=1
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.hspa=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.lte=524288,1048576,2097152,524288,1048576,2097152
net.tcp.buffersize.hspda=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.evdo_b=6144,87380,1048576,6144,87380,1048576
windowsmgr.max_events_per_sec=90
I couldn't say for sure that I have seen an improvement, but I think I've seen some improvement in overall stability/multi-tasking. At least, there have been no ill effects. I am also getting better data speeds in certain parts of town via T-Mo - but that could be random or related to experimentation with my APN.
Also...VOLTE is enabled by default in the stock build.prop - unfortunately it is a known issue that Huawei phones don't get VOLTE on T-Mo (in the US) unless they have US firmware.
Click to expand...
Click to collapse
You mean you added and edited these lines in the vendor build.prop right?
The I can't mod the system build.prop, after every restate it restores the old one. What can I do about it?
Marcopoloy13 said:
You mean you added and edited these lines in the vendor build.prop right?
The I can't mod the system build.prop, after every restate it restores the old one. What can I do about it?
Click to expand...
Click to collapse
I think the system/build.prop is rewritten according to the vendor/build.prop at boot. I'm not sure. You don't have to do anything about it - just edit the vendor file instead of the system file.
Be careful with heapsize values. I pushed the dalvik.vm.heapsize to 900m, with .6 heaptargetutilization - and it bootlooped me. I had tested those values on my Sony Z3TC first and they worked...
Don't know exactly what difference it makes, but I am currently using:
dalvik.vm.heapsize=720m
dalvik.vm.heapstartsize=36m
dalvik.vm.heapgrowthlimit=144m
dalvik.vm.heaptargetutilization=0.67
thref23 said:
I think the system/build.prop is rewritten according to the vendor/build.prop at boot. I'm not sure. You don't have to do anything about it - just edit the vendor file instead of the system file.
Be careful with heapsize values. I pushed the dalvik.vm.heapsize to 900m, with .6 heaptargetutilization - and it bootlooped me. I had tested those values on my Sony Z3TC first and they worked...
Don't know exactly what difference it makes, but I am currently using:
dalvik.vm.heapsize=720m
dalvik.vm.heapstartsize=36m
dalvik.vm.heapgrowthlimit=144m
dalvik.vm.heaptargetutilization=0.67
Click to expand...
Click to collapse
I don't think that the vendor and system ones are the same or will be generated from it, there are not the same, things like dalvik.vm.heapgrowthlimit isn't in the system one just in vendor.
I have instead an GSI, so there are very different .
For Example on the system one it says the right security patch and release (8.1.0 - 2018-07-05) while on the vendor one it is still the values from the EMUI Rom (8.0 - 2018-06-01)
So there must be a way to mod the system build.prop, the MagiskHide Props Config Module runs a script on startup to modify the fingerprint, but I don't know how to modify more that this with this module or write my own script.

Categories

Resources