Related
So,
Since the release of the kernel, there is oviously some work going on to optimise the ROMS, and I currently have the following setup.
Modaco 2.2 cooked ROM with custom kernel, and with compcache enabled.
It certainyl feels pretty snappy, but it always did with Spare Parts helping with the visual effect of speed.
I guess what I'm asking is if there is a way of checking to see if my phoe is actually utilising the compcache correctly, and if there are any other apps or scripts I can run to check if everything is ticking along nicely.
for example, I have meminfo installed, but I'm pretty new to all this, and I'm not sure what numbers I should be looking at , and what their values should be, to indicate that everything is nice....
Like I said, it's pretty snappy right now, and I have no complaints, but I just would like to get a handle on numbers to make sure I'm in the right ballpark.
Hoping someone can shed some light....
Shell into adb on your computer and type:
Code:
# free
Or download a terminal program from the marketplace and do the same on your phone.
You should see numbers in the Swap row of the data it returns.
Good question. I just flashed modaco's 1.2 Kernel over Fresh 1.1. Thus far I've noticed a big speed boost in dialing and loading apps. The Dialer speed is major at it used to be my biggest complaint with the Hero. Hit a contact and wait like 5 seconds or more .I have no way to verify though.
Tikerz said:
Shell into adb on your computer and type:
Code:
# free
Or download a terminal program from the marketplace and do the same on your phone.
You should see numbers in the Swap row of the data it returns.
Click to expand...
Click to collapse
total used free
Mem: 195916 193684 2232
Swap: 131064 90256 40808
Total: 326980 283940 43040
#
I'm worried about my Mem Free number (2232)
Doesn't seem a lot....??
I removed all of the # using es explorer, but it keeps giving me an error when trying to save it. Can someone please post instructions on an alternate way to enable compcache
noonanjs said:
I removed all of the # using es explorer, but it keeps giving me an error when trying to save it. Can someone please post instructions on an alternate way to enable compcache
Click to expand...
Click to collapse
I actually had the same problem. What I did was uncheck remount as read/write, re-check it, and after that was able to save the file, reboot and jus like that it was done
Update: I installed Spare Parts, as mentioned by appelflap later in this thread, disabled compatibility mode, then followed the directions in this post, and I have a working status bar, good resolution, and in a better place in most cases.
Update: Check out appelflap's APK that makes this whole process a lot easier. Note that some users are reporting a black screen after using the file, so be prepared in case you have to use adb shell to put your original build.prop file in place. If you do not want to risk it, Notepad++ makes for an easy edit once you pull the file to your PC. If you have fallen prey to the black screen problem, lpsi2000 found a solution that uses an update.zip approach.
In the /system/build.prop file, I changed this line:
ro.sf.lcd_density=240
Click to expand...
Click to collapse
to this:
ro.sf.lcd_density=160
Click to expand...
Click to collapse
This is a setting that Google normally recommends if you have a larger screen (like Dell's Streak), but the side effect of using it on the 800x480 screen of the captivate is that everything is smaller.
With this, menus have smaller text (more options on screen), in-app buttons are smaller, and it just has the same feeling of being on a PC and moving from a low resolution LCD monitor to a high resolution LCD monitor.
There are a couple of glitches so far. It appears that some apps want to render in the previous resolution. For example, Skyfire and Root Explorer would not render in full screen, Android Market renders full screen but the search is in the old resolution, and the status bar is slightly garbled but still usable. Also, the dial pad is smaller (as you would expect showing a picture made for a low res display on a high res display) but the rest of the phone app is fine. The camera app fills the screen just like it did before.
With this setting, I really feel like I'm getting some use out of the high resolution display on this phone.
The apps that are rending in the low res mode of the original setting seem to be pulling their setting from somewhere else. Does anybody have an idea where that setting may be? After trying this, I can't imagine going back to what almost seems like an "accessibility mode".
I've only used LauncherPro with this setting, so no idea how the Samsung launcher looks. I attached screenshots of what some things look like. I can put some game screenshots in another post if anybody is interested. 3D games look sharper to me in this mode, but I have no scientific way of testing if it is because it is rendering in higher res or if my own excitement is clouding my vision.
Update: I suspect the missing setting is found in the /system.prop file. It has the ro.sf.lcd_density=240 setting. I tried changing it to 160, but it keeps going back to 240 after a reboot of the phone. Any ideas how to make this stick?
Warning:: TWLauncher does not play well with these changes. Make sure to have LauncherPro set up as your default launcher before trying this.
So you're pulling it off the cappy then editing putting back....do you need to change permissions?
The way that I pulled it out to edit on my PC was with this:
adb pull /system/build.prop
Click to expand...
Click to collapse
You will need root access in order to put the changed file back. What I did was
adb push build.prop /sdcard
Click to expand...
Click to collapse
I then used Root Explorer to copy the build.prop from /sdcard to /system. I didn't change any permissions other than just copying the file and rebooting.
Wow man that's pretty cool, it's got a few little glitches but nothing serious. One of the things I wish I could so though is make my Beautiful widgets clock go all the way across the top. I'm not sure if this is a placebo effect (I donno if that's possible since this should have nothing to do with it) but it seems like my soft buttons respond more often....I'm prolly nuts but it doesn't seem like I need to push....push...%$^&*^ PUSH.....and back to home.
I'm hoping someone will have a great idea on how to keep the /system.prop file from updating itself on boot. I'm thinking that if we can get the ro.sf.lcd_density=240 setting to stick to 160 after a reboot, that might fix the few instances where an app won't render full screen.
I've tried chmod 666 system.prop and chown root.root system.prop but it still gets returned to normal after rebooting.
Wow I'm excited to test this out. Couldn't we get someone to code this into the startup script theoretically?
Edit: Tried it out. Really really nice. If only we could get the rest of the apps to work the right way... right res.
One thing also that's cool is in launcherpro you can add more columns to the drawer so you can fit an insane amount of apps on screen.
Sent from my GT-I9000 using Tapatalk
Also out of curiosity, have you tried any other DPI like 200? Our does it need to be either or to keep it proportional?
Sent from my GT-I9000 using Tapatalk
Lower resolution works as well. Here are some comparisons. 160, 240, 320. 200, since someone asked.
wow, this could REALLY be nice.. Just need to fix everything, but like others have said no HUGE things that cause it to be unusable, but I would love to see everything correct.
Also out of curiosity, have you tried any other DPI like 200? Our does it need to be either or to keep it proportional?
Click to expand...
Click to collapse
No, the only reason I chose 160 was because it is listed as "MDPI" in the Android SDK. (We were using "HDPI" with 240.)
I only figured it was a "supported" number, so I started there, but most any number will do. You can see a chart where it recommends certain numbers based on resolution or screen size, but I think these recommendations are to cover everybody, which includes folks who can't (easily) see small text or icons.
The chart that shows Google's recommendations is here.
reading around, it seems that the files need to be put back to read only.
phlunkie said:
reading around, it seems that the files need to be put back to read only.
Click to expand...
Click to collapse
I thought so also, but you don't need to. All I'm doing is copying it with root explorer to sd, then using astro to edit the line and root explorer to put it back. Reboot and your GTG. Everything works fine.
Sent from my GT-I9000 using Tapatalk
So the settings are sticking after a reboot? I will have to try this when I get home.
Sent from my SAMSUNG-SGH-I897 using XDA App
phlunkie said:
So the settings are sticking after a reboot? I will have to try this when I get home.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
After I edited the build.prop and the build.prop.bak files in the /system directory it works fine after reboot. A problem that I have is that TouchWiz force closes after editing the files.
Using this on SGS made:
- notification bar unreadable (kindof text overlap@240160 setting).
- Launcher pro works.
- Market scales nice.
- big list's buttons are now nice
//edit: changed to 200 - seems to be great compromise.
@up
Bad practice. U shouldnt have edited ur build.prop.bak file, becouse it is actually a backup of original build.prop, made by RootExplorer (guess). In case u want to revert to original content, u just delete edited file and delete .bak from this one.
xan said:
Using this on SGS made:
- notification bar unreadable (kindof text [email protected] setting).
- Launcher pro works.
- Market scales nice.
- big list's buttons are now nice
//edit: changed to 200 - seems to be great compromise.
@up
Bad practice. U shouldnt have edited ur build.prop.bak file, becouse it is actually a backup of original build.prop, made by RootExplorer (guess). In case u want to revert to original content, u just delete edited file and delete .bak from this one.
Click to expand...
Click to collapse
Any pics? Love to see the difference.
Sent from my Nexus One using XDA App
Here they are.
I'm trying to figure out how to make those other applications also use the full screen when at a different resolution. I tried the method here
http://forum.xda-developers.com/showthread.php?t=739647
to run a script that rewrites the /system.prop file, and it didn't fix anything, so either that is not where the applications are getting the property from, or we need to rewrite the file earlier in the boot process.
Are you sure those apps are graphically able to scale? Maybe touchwiz does not take scaling into account (at least with native apps) because the screens are all 4 inches.
edit: Most devs have added this to their roms already so don't be surprised if you find it in the build.prop already.
So I saw this mentioned in a tweet by the dev for Launcher Pro:
To get really nice smooth scrolling on your Eris add the following line to your build.prop:
Code:
windowsmgr.max_events_per_sec=60
To add it into your build.prop follow these steps using your adb tool:
Code:
adb remount
adb pull /system/build.prop
(Go into your tools folder and open it with notepad. Add the line I posted and save.)
Code:
adb push build.prop /system/build.prop
Reboot into recovery, wipe dalvik cache, and start the phone up. This can a while to boot up right after because of the wiping dalvik cache. You should notice that scrolling on your phone is much smoother.
I AM NOT RESPONSIBLE FOR YOUR PHONE. IF YOU BREAK YOUR PHONE DOING THIS (it's unlikely!) I AM SORRY BUT I CAN'T HELP YOU.
I currently have mine set to 70 and it's not any noticeably smoother than 60 that I can tell but it is stable so if anyone wants to try bumping it up to 90 or 120 feel free.
Thanks for the advice last night on this Hungry Man. I did this and notice a definite difference in the scrolling. I moved my Launcher pro scrolling speed down now from 100 to 45 because I no longer need it high with this fix. I also didn't wipe Davlik after pushing, but the file is in there when looking with Estrong file manager and the scrolling is definitely better now..
Thanks again..
Glad I could help! Wiping the Dalvik cache isn't really necessary I suppose, I just find it's good practice after doing anything to your build.prop to avoid possible glitches.
any reason why this wouldnt work on other devices?
Where exactly do I add this line? Thanks.
dev/null/ said:
Where exactly do I add this line? Thanks.
Click to expand...
Click to collapse
Just add it to the end of build.prop file.
Worked, I thank you for the reply and to the OP for the info.
Twidroyd
Could I get someone to fire up Twidroyd after applying this patch? Seems to cause super-heavy lag+slowdown in scrolling, but it appears that Twidroyd is the main offender.
This seems to work just fine for me. I guess it seems smoother... I can't really tell. Definitely not laggier.
Wouldn't you be able to open the build prop in something like Root Explorer's text editor and get the same result? I'm just not around my regular computer with adb setup... Thanks.
es0tericcha0s said:
Wouldn't you be able to open the build prop in something like Root Explorer's text editor and get the same result? I'm just not around my regular computer with adb setup... Thanks.
Click to expand...
Click to collapse
yes you can do this also.
Sent from my FroyoEris using XDA App
Implemented this tweak in my latest ROM and it definitely makes a difference
Sent from my nonsensikal froyo
I tried obtaining access through Root Explorer and it says that build.prop is read only?
drtchocky said:
I tried obtaining access through Root Explorer and it says that build.prop is read only?
Click to expand...
Click to collapse
You have to remember to make the directory R/W at the top of the screen.
Can't really tell if it made a difference. Has anyone experimented with setting the number even higher?
EDIT: Upon further review, it seems to have made my scrolling slightly smoother but also more likely to 'hitch'
Yeah, I think this is what I was seeing in Twidroyd. Scrolling is smoother in a list you've already scrolled through, but will stutter as it loads new table cells (a guess on my part, but it seems to make sense.)
Izeltokatl said:
You have to remember to make the directory R/W at the top of the screen.
Click to expand...
Click to collapse
Thanks! Rebooting now....
I think it's likely that if you aren't overclocking your phone may not be able to handle the extra load. If you aren't overclocking your phone or you're usually on a low cpu setting try chaing to 50. Anything above 35 will increase the smoothness, though not to the same extent. I don't suggest passing 60, I'm at 70 and the differences are negligable.
As for the lag and stutters, I haven't experienced that.
I did it. Didn't break anything, but didn't really seem to change anything either.
I have seen a huge difference in smoothness in screen scrolling as well as app drawer. I have large amt of apps and app drawer flies. One thing though I do not have a space before or after the equal sign on my line. Some of you who aren't seeing a huge difference take the spaces out and see if anything changes.
What is the purpose/benefit of these options?
Underground_XI said:
What is the purpose/benefit of these options?
Click to expand...
Click to collapse
rendering a view goes through layers or abstractions, even passing through dedicated hardware doing the job. hardware overlay allows the renderer to take a couple of regions aside and treat them optimized. then theres the cpu and gpu. usually android decides which abstraction is best for each view, taking things like transparency into account and what not. you switch hw overlays off, project butter goes out of the window but cpu and gpu still do the job. you force gpu, the composition will be done by your gfx chip. just don't touch it - its meant for developers picking up debugging output.
Root
molesarecoming said:
rendering a view goes through layers or abstractions, even passing through dedicated hardware doing the job. hardware overlay allows the renderer to take a couple of regions aside and treat them optimized. then theres the cpu and gpu. usually android decides which abstraction is best for each view, taking things like transparency into account and what not. you switch hw overlays off, project butter goes out of the window but cpu and gpu still do the job. you force gpu, the composition will be done by your gfx chip. just don't touch it - its meant for developers picking up debugging output.
Click to expand...
Click to collapse
I am rooted, and I'd like to know wether this does improve performance of the CPU cuz the GPU is rendering the stuff. I don't care about the battery.
Thanks in advance
You won't notice any considerable improvements. But can cause unintended side effects in apps (mainly embedded images not displaying)
Sent from my Nexus 4 using xda app-developers app
Make Disable HW Overlays Pernment
View attachment 91fixoverlays.zip
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Code:
#!/system/bin/sh
(while :
do
sf=$(service list | grep -c "SurfaceFlinger")
if [ $sf -eq 1 ]
then
service call SurfaceFlinger 1008 i32 1
break
else
sleep 2
fi
done
) &
Alex240188 said:
You won't notice any considerable improvements. But can cause unintended side effects in apps (mainly embedded images not displaying)
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
dear Mr Alex you are right you may not notice any discernible difference but you free up to cpu to do more especially if you're writing intensive apps.my advice keep it on free that cpu baby
Very nice script. Working nice on 5.1.1
sgatechwork said:
View attachment 2741805
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Click to expand...
Click to collapse
thanks for the script!
Indeed. I specifically logged in, just to be able to thank the dev. I reject the whole "take and run" thing.
Ziontist said:
Indeed. I specifically logged in, just to be able to thank the dev. I reject the whole "take and run" thing.
Click to expand...
Click to collapse
How to run the script?
24imelqui said:
How to run the script?
Click to expand...
Click to collapse
Simple way is to use a working init.d script. Open it using a Text Editor and erase all lines. Copy the lines from sgatechwork to the file and save it to /system/ect/init.d. There are some Apps to emulate init.d if your ROM/Kernel does not support it.
But if you don't know how to use it, why do you want to use it? Do you know what it does?
Thanks @sgatechwork !
24imelqui said:
How to run the script?
Click to expand...
Click to collapse
Odd. I don't recall ever seeing or posting in this thread, and I haven't installed the script. Seems about par for the course for me. Anyways, I read about it, and it sounds like a nifty script. Since you say script (and I would concur, based on the lack of a file ext., and the file size)... it would be placed in the init.d folder in system/etc/init.d, as long as your kernel supports init.d. If not, there are apps to run scripts w/o init.d support. The one I know of is Boot Shell [ROOT]. Also, there's an app that lets you choose which folder you wanna run your scripts from, called init.d Scripts Support. However, the most recommended init.d managing app, based off of what I've read most people recommending, is Script Manager - SManager (there's also a paid ad-free version Script Manager-SManager(NoAds)). Hopefully at least some of this is found helpful. Sorry the response is so late. :?
shaktishekhar said:
View attachment 2741805
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Click to expand...
Click to collapse
Thanks so much, it worked nicely on my Sony Xperia S (aka Lt26i) on stock rom, with init.d support (Universal init.d support)
:good:
Hi there. I wonder if it's possible to disable GPU rendering in lollipop. My phone is still using gpu to draw the UI even after I uncheck 'disable HW overlays' from developer options. I am having lag issues while playing games. I think it's because System UI is always using GPU and as a result my games are laggy, but those same games work perfectly fine on kitkat without any lags.
I can see GPU usage curve spiking from 40% to 80% all the time in system monitor.
shaktishekhar said:
View attachment 2741805
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Code:
#!/system/bin/sh
(while :
do
sf=$(service list | grep -c "SurfaceFlinger")
if [ $sf -eq 1 ]
then
service call SurfaceFlinger 1008 i32 1
break
else
sleep 2
fi
done
) &
Click to expand...
Click to collapse
Thanks for script works on CM12,1
Underground_XI said:
What is the purpose/benefit of these options?
Click to expand...
Click to collapse
Don't touch force gpu rendering. But disable hw overlays reduces lags in system animations when u browse your phone. I use this cause I hate animations lag. But note that when enabled it'll cause little lag in gaming.. so it's your choice.
shaktishekhar said:
View attachment 2741805
Script To Make Disable Hardware Overlays Permanently On Boot use the script using init.d or script manager or boot shell :laugh:
Code:
#!/system/bin/sh
(while :
do
sf=$(service list | grep -c "SurfaceFlinger")
if [ $sf -eq 1 ]
then
service call SurfaceFlinger 1008 i32 1
break
else
sleep 2
fi
done
) &
Click to expand...
Click to collapse
Genius.
So the dev section here has been active recently with some high quality work, and I am looking to add to the fun
**SEE POST 2 FOR CHANGE LOG**
***VERY IMPORTANT IF YOU ARE GOING TO USE THIS MOD, you need to navigate to the /system/etc folder on your device, and rename the file "init.lge.zramswap.sh" to "init.lge.zramswap.sh.bak" so it does not run at boot.
This is a step by step instruction on how to replace the /system/etc/init.qcom.post_boot.sh file for the LG V10. Be it known, however, that this instruction (and file) can be used with any device running the Snapdragon 808 SoC combo.
What does this do?
Simple. It turns your device into an even more efficient powerhouse. Here are is a list of everything done:
-Interactive Governor tuning for performance and better battery life, a quick description of what I did...
-low load, quick response, low frequency
-high load, quick response, higher frequency
-modified input boost settings for Interactive
-Adjusted GPU target load values
-Switched IO scheduler to noop, and tuned accordingly
-Adjusted minfree values (RAM management, it is a little more multi-tasking friendly)
-Adjusted VM parameters - swappiness, dirty ratios, cache pressure, centisec values, etc (again to complement multi-tasking... your data will hang out a little bit more before being written to disk, but house cleaning won't happen all at once, so there is still good performance and your system won't bog down while it is flushing the toilet)
-DISABLED zRAM!!! - I have no idea why a device with 4 GB of RAM has zRAM enabled. This is purely a waste of CPU cycles and other system resources. You want physical memory, not compressed memory.
-Changed congestion algorithm to cubic (better network performance... assuming the network bandwidth is already there
-Cleaned up the shell file and fixed some errors.
-More to come!
How to do this, we'll just get right to it.
Download this app https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en
Download this file https://drive.google.com/open?id=0BzM9W6qUvx-gcm1SVDhsTDVWZ3M
And while you are here, check this out, decide which one you want.
http://forum.xda-developers.com/showpost.php?p=66792862&postcount=109
Very important you put the file on the root of your INTERNAL SDCARD!!!
Do not forget to do this.
After you do that, open terminal emulator, and type the following commands in the order they are presented (I would highly recommend just copying them from this post and switching back and forth between your browser and the terminal app):
Code:
su
Code:
cd /
Code:
mount -o remount,rw /system
Code:
cd /system/etc
Code:
rm init.qcom.post_boot.sh
Code:
cd /sdcard
Code:
mv init.qcom.post_boot.sh /system/etc
Code:
chmod 0644 /system/etc/init.qcom.post_boot.sh
Double check the file has been replaced with a file explorer of some sort, double check permissions, then reboot. Good to go.
Some of this stuff explained http://forum.xda-developers.com/tmo...nux-virtual-machine-explained-part-1-t3386956
CHANGE LOG***
May 1, 2017
-Pretty major overhaul of the file. I've done some stuff on the Axon 7 that has been pretty effective. Rolling those changes out to other devices. https://drive.google.com/open?id=0BzM9W6qUvx-gcm1SVDhsTDVWZ3M
May 31, 2016
-Replaced corrupted files. Good to go now!
Dangerously version (fixed) https://drive.google.com/open?id=0BzM9W6qUvx-gVHBGWEp3QkpURVE md5sum: a632c866e22114c0e18fa335f005293e
May 25, 2016
Quite a bit of changes here...
-VM completely readjusted. vfs_cache_pressure set back to default 100 to fairly reclaim memory pages that have been allocated to block specific data about file location, etc.. there are tons of write ups on this stuff if you guys want to investigate more into what this setting does, how it works. It's basically a fairness multiplier centered around a value 100. + or - that value increases or decreases the probability that the kernel will reclaim those certain memory pages relative to swap.
-Swappiness reduced drastically... from 80 to 40 (default is 60 depending on which kernel you are running)
-dirty ratio and dirty background ratios reduced drastically to avoid massive amounts of data being flushed and causing system hangups when that ceiling is hit. (lol this happened to me... system ran out of mem... *shrugs* I go hard bros)
-Increased the probably of the system to reclaim memory pages, and made a pretty big adjustment to writeback_centisecs and expire_centisecs
-Changed functional aspects of the interactive governor again - it is perfect. Nominal user experience. Same with touch input_boost. This system definitely has a sweet spot, and I'm pretty sure we've found it now.
-Decided to ditch the laptop mode idea and not mess with the RAM console outputs, the functional loss wasn't returning enough reward. So, here we are.
-Adjusted minfree once more, to
-It is important to note that the system will, admittedly, not multitask quite as aggressively. I had to do this, however, for myself mostly. As I was achieving OOM conditions and hitting the high ceilings set in other parameters like dirty_ratio and when it hits that wall, man it hits hard. Complete lock up for a good 40 seconds while everything is getting dumped from memory. I need a phone with more RAM lol. Didn't think that would ever happen on my mobile set up with 4 GB of it but here we are. I suppose I could re-enable zRAM for myself? But that would hardly help as compression ratios aren't going to yield me an extra gigabyte. Ok now I'm rambling. DOWNLOAD THE FILE!
Very interesting, I'll be trying this in the next hour or so! Thanks for posting.
Edit: Made changes as per the instructions and rebooted successfully. No issues so far, we'll see! Thanks again.
Nice...
Desde V10 (LG-H901)
For all variants? Is it compatible with H961N LP?
Looks promising and wanted to try.
How do I know it worked? I followed the steps
Sent from my LG-H901 using XDA-Developers mobile app
roosxter said:
How do I know it worked? I followed the steps
Sent from my LG-H901 using XDA-Developers mobile app
Click to expand...
Click to collapse
After every line he explains what it does, you would recognize the changes through your usage or maybe non-usage (as far as battery life and RAM management goes)
When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #
iamtheon said:
When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #
Click to expand...
Click to collapse
i got problem with the !!!!!!cd /sdcard , writing
i tried cd /storage/emulated/0
and worked for me
11868 said:
i got problem with the !!!!!!cd /sdcard , writing
i tried cd /storage/emulated/0
and worked for me
Click to expand...
Click to collapse
I tried that, but doesn't hurt trying again.
Edit: It worked. I did the same thing lol oh well thanks @11868
Can this be done with the root explorer instead of terminal emulator?
So this can be used on the G4? And does this overwrite settings within the kernel? If I push this file and I don't like the results can I flash a kernel to get rid of the changes?
iamtheon said:
When I try to move the file it's giving me this error. I have BusyBox and pretty sure it's on read/write access. What am I doing wrong -_-
1|[email protected]:/ # mv init.qcom.post_boot.sh /system/etc
mv: init.qcom.post_boot.sh: remove: Read-only file system
1|[email protected]:/ #
Click to expand...
Click to collapse
Your system wasn't mounted as rw when you executed the command
agrenwa said:
Can this be done with the root explorer instead of terminal emulator?
Click to expand...
Click to collapse
It can, yes, I just prefer the old school way. You can manually drop the file in the /etc folder after deleting the previous one. Just need to make sure the permissions are set appropriately.
klbjr said:
So this can be used on the G4? And does this overwrite settings within the kernel? If I push this file and I don't like the results can I flash a kernel to get rid of the changes?
Click to expand...
Click to collapse
Yes, this can be used on the G4 and any other device using the Snapdragon 808. Overwrite settings within the kernel? No, I wouldn't say that. sysfs is more of a userspace / virtual file system that allows you to interact with the hardware... but the parameters we are working with here are completely writable, not permanent, and more important, will reapply AFTER boot. So, no, flashing a kernel will not revert the changes. If you want to go back, you'll need the original file to replace mine with.
Hope this answers your questions.
Since the file is hosted on Dropbox, anyone who has a dropbox account please choose the login option, and transfer the file to your dropbox before downloading it from your own storage to avoid OP's dropbox being blocked for too many downloads in a row.
Good Job OP, nice to see Junior Members doing something great in the dev section
So I did it last night, and so far battery life seems to be much worse than before when nothing has changed but these tweaks. Any idea why? Battery stats is the same for me as usual with the exception of Android System being at 6% and Android OS at 6% use each.
So far so good, not sure what battery usage will be like. I had terrible lag in a game called Underworld Empire and that has disappeared! How badly was the kernel/system coded before?!
Question , how come your file is smaller than the original? Was there a lot of excess code that was useless?
Sent from my debloated rooted LG V10 using Tapatalk
rirozizo said:
Since the file is hosted on Dropbox, anyone who has a dropbox account please choose the login option, and transfer the file to your dropbox before downloading it from your own storage to avoid OP's dropbox being blocked for too many downloads in a row.
Good Job OP, nice to see Junior Members doing something great in the dev section
Click to expand...
Click to collapse
I'll try to upload the file elsewhere, didn't consider that. However, it is a very small file and dropbox might not notice/care. Good observation.
danstheman7 said:
So I did it last night, and so far battery life seems to be much worse than before when nothing has changed but these tweaks. Any idea why? Battery stats is the same for me as usual with the exception of Android System being at 6% and Android OS at 6% use each.
Click to expand...
Click to collapse
Coincidence maybe? Keep monitoring, report back.
Also, bear in mind: rebooting your system causes a little more activity within the OS the first day or so (particularly google services) and it does have an effect on battery drain.
amoot329 said:
So far so good, not sure what battery usage will be like. I had terrible lag in a game called Underworld Empire and that has disappeared! How badly was the kernel/system coded before?!
Question , how come your file is smaller than the original? Was there a lot of excess code that was useless?
Sent from my debloated rooted LG V10 using Tapatalk
Click to expand...
Click to collapse
Yes, it is smaller because I removed everything that was not relevant to the msm8992 SoC. Qualcomm uses common files for just about everything and anything they can - saves them time, hassle and consolidates work somewhat.
Most of the content removed from the stock file is for other platforms not relevant for us.
warBeard_actual said:
I'll try to upload the file elsewhere, didn't consider that. However, it is a very small file and dropbox might not notice/care. Good observation.
Click to expand...
Click to collapse
I recommend Google Drive or Box
@warBeard_actual
Great job buddy on this.... @freeza mad af!
To everyone else I've been using this for a while and am happy to report my buddy warBeard_actual has been killing it!
bencze, proof or it didn't happen