Related
Hi,
I'm choosing a phone for my father who's hobby is a chess. The best chess program for Android is probably Droidfish. It is based on one of the fastest, free and opensource (GPL3) chess engines, called Stockfish. Performance in Chess depends mostly on CPU integer manipulation speed and memory system speed (RAM, RAM caches). Chess program scale very well on to multiple CPU core machines (at least on PC). So when I noticed the price of LG O2X is similar to HTC Desire S which I intended to buy for him (because I have good experience with original HTC Desire), I got intrigued by two cores. Can somebody do a performance test on Chess for me? Exact steps are below.
Step to measure:
1) Install Droidfish: https://market.android.com/details?id=org.petero.droidfish
(there are several clones in the market, but this one comes from author of the UI, Peter Österlund, see here http://web.comhem.se/petero2home/droidfish/index.html )
2) Run Droidfish
3) Press menu button, invoke "Settings", activate option "Show computer thinking" in "Hints" section. Press back button.
4) There is button with label "M" below chess board. Press it. Choose "Analysis Mode". Analysis will start. Keep it running for about 1 minute. You can watch time in "t:" field in status at the botom, but it updates only occasionally.
5) After 1 minute passed, read "nps:" field in status. This is the measurement I'm interested in. On my HTC Desire I get values in range of 80000 to 90000. This value is a number of positions searched per second. Higher is better. This number depends on position (we used initial position; some positions are faster to search) and depth searched.
6) To force program to stop thinking, press "M" button again, choose "Two players" so that analysis will stop.
Unfortunately, the test is not repeatable since chess engine remembers previous findings which may affect the speed. If you want to repeat the test, go to Android's main settings, choose "Application", then "Manage Applications", find Droidfish, press "Force stop", press "Clear data" and confirm. You can repeat test now.
Thank you in advance for measuring!
Attached screenshot of Droidfish.
I am running CyanogenMod 7 Nightly, it might be faster on other roms, who knows
Hi
did get 101527 in first attempt after 60 seconds
second attempt gave me 102200, again after 60 seconds
im on FR13 Modaco Rom
I got 102628, on CM nightly 1
About 102k+ on stock firmware (v10b), unrooted.
That was fun
me too about 102500 is the lowest score and about 103200 is the highest score.
Running rooted stock rom with pauls tweaks/patches.
Thank you all for measurements.
So values are
HTC Desire - about 84000 nps
HTC Desire S - about 90000 nps (I measured once in HTC shop)
LG Optimus 2x - about 102000 nps
All of these processors run at 1GHz. But that can process different number of instructions per cycle. These values are expected as Desire S has very slightly improved processor and single core of Optimus 2x is slightly better at that as well according to what I have read about the processor. But it also means that the program is unable to use two cores.
With two cores, I would expect values like 140000 to 170000 nps (based on how these programs scale to multiple cores on PC). I don't know why two cores are not used. The support for more cores is quite new in Droidfish (Changelog entry indicates: "2011-01-02: Version 1.26 - Made stockfish use all available CPU cores"). And probably untested on variety of phones. Code to detect number of processors is also strange (DroidFish/src/org/petero/droidfish/engine/DroidComputerPlayer.java, where method getNumCPUs() gets number of processor by parsing /proc/stat ). Maybe it has something to do with only Android 2.2 not fully supporting multi core CPUs. So it might be interesting to retest once update to 2.4 is available. Or is there any expert on multicore programs in the 2x with different explanation?
Android 2.2 supports several cores, contrary to popular belief. Single-threaded apps (that'd be most crap on Market) won't do too good however. The issue in this case I'd say is because of suboptimal LG firmware (which no doubt will be improved with LG's implementation of Android 2.3).
These are my figures using another ROM, based on LG stock Android 2.2; Modaco ROM for LG Optimus 2x.
It is not overclocked.
drcorwe said:
Android 2.2 supports several cores, contrary to popular belief. Single-threaded apps (that'd be most crap on Market) won't do too good however. The issue in this case I'd say is because of suboptimal LG firmware (which no doubt will be improved with LG's implementation of Android 2.3).
These are my figures using another ROM, based on LG stock Android 2.2; Modaco ROM for LG Optimus 2x.
It is not overclocked.
Click to expand...
Click to collapse
Wow, you have got the result I expected from using both cores. 195k nps is great.
Modaco ROM must be good! At least it reports numbers of cores in /proc/stat in a way that Droidfish succesfully parses and allows to run multiple threads of the same process on both cores.
Edit: just for a comparison, since measurement was done later than 1 minute, I ran the test until I got about 24 million positions ("n:" label), it took 274 seconds on HTC Desire (87506 nps). So O2x is 2.25x faster the Desire.
Updated screenshot. Force stop droidfish->clear data->reboot phone.
Ran for 60s.
I tried this on a Samsung Galaxy S2, 250,000-266,000!
Screenshots?
Here goes:
Hi all
I very much doubt this post belongs here, but since i am a new member , have no chice but to put it here.
I have recently accidentally purchased a nexus7 (grouper) and decided to try some of the custom roms available, in the end i tried most of them.
Here are my comparison results.
As with all things putting an "order" on the roms is subjective, the "best" rom is the one that works for the individual,with that individuals particular needs and wants.
As an embedded design engineer i am obsessed with speed and efficiency, memory usage, putting as much data on the screen as possible, then finally compatibility and lack of bugs ( in that order ), my results are biased by that order.
Disclaimer........
1) Ok i know that android is not exactly ideal if looking for an efficient well written os ( who the F came up with the idea of running everything in a VM!!! a minimal linux system will run in 85 mb ram with a full xserver, android STARTS at 400mb+, sitting there doing nothing !!!, thats near my cut down windows7 running on an i7 ) but before a decent linux distro is ported to full touch am stuck with it
2) For the N7 the requirement to change the DPI is essential, it is VERY stupid that the os does not check and change this automatically, otherwise its like having your 1920x1080 monitor stuck on 1200x600 permanently, very stupid !!! So am assuming the roms without this facility will function at 160dpi correctly, i have not been able to check this for every rom
All roms were flashed by TWR ( latest ), wipe of cache, dcache, factory reset, system
Memory was checked by settings>apps>running , immediately after first boot, then after a clean reboot, then after a cache,dcache wipe and clean reboot
IMPORTANT NOTE.....
Google apps ( gapps)...... in terms of memory usage gapps is the worst peice of #%%#%%$#$% sh$%^%$%t bloatware i have ever encountered in my os experience ( and given that i spend most of my time in windows, that saying something ).
On any of the roms i have tried flashing gapps adds at LEAST 150mb of unneeded memory usage, and depending on the rom that can go up to 250mb. Even using a minimal gapps with only phonesky,framework,login and setup, still produces a significant 50+mb hit, unfortunately in many cases some of gapps is essential, and some os functions are broken without at least the framework.
This situation seems unacceptable to me, all the roms should function correctly without gapps, and without the bloat, if some dev does not address the situation i will.
1) Prime Grouper D03-06
Tablet ui...... yes
DPI changer ...yes
Size custom nav bar ....yes
Speed....... good
Response ... good
This is first on the list for 1 good reason, memory usage!!!
Before flashing any kind of gapps
First reboot 360mb
Second reboot 320mb
Cache wipe reboot 270mb
Subsequent reboots 266mb ( stable )
Obviously team Vanier know their sh**t, their os is running in nearly HALF the memory space of other roms , and on the whole with few bugs, but whats really impressive is the memory usage is incredibly stable for a android os, zero memory leaks, leave the device at 302 mb ( say you opened an app and it was cached etc ) for 24 hours check again and lo and behold its still roughly 320mb ( obviously internal processes are moving this number a little but only by <>5mb ), this is not the case with stock rom or many other custom roms.
Everything is not all roses though, using prime without flashing gapps at all, exposes quite a few bugs, notification panel does not work at all, clock settings is broken, a few apps fail ( mx player fails for a start ) and others.
Flashing a super minimal gapps, fixes most of the issues, notifications are back, a lock screen turns up, all the settings appear fixed, BUT it also knocks out vanires keybord and totally ruins the memory handling
After flashing "micro" gapps ( and going through setup, adding valid account etc )
First reboot 430mb
Second reboot 360mb
Cache wipe reboot 320mb
Subsequent reboots 360mb ( NOT STABLE, can vary up to 400mb+ with time )
Obviously would love to see PRIME fix the outstanding bugs, and produce a custom set of gapps apk's that dont screw this fine rom.
2) Smooth ROM v5
Tablet ui...... yes
DPI changer ...no
Size custom nav bar ....yes
Speed....... good
Response ... excellent ( the best )
Gapps are included
First reboot 470mb
Second reboot 4200mb
Cache wipe reboot 400mb
Subsiquent reboots 440mb ( NOT STABLE can go 500mb+ )
This rom is second due to a totall lack of bugs, after much mucking around i can not find a single setting or feature that does not work correctly, plus the UI is very very responsive, the best of all i have tried. It would be top but for the lack of a DPI change option and the fact that memory usage is nearly double that of PRIME.
will post the other 20 odd results later
What's more interesting is that identical apps on the galaxy S3 take up 2-3 times more memory. 1GB is fine on the N7 but you have to do a lot of fiddling to get the S3 running with 1GB. Must be down to the Tegra architecture. Smooth 5 runs great on the N7 (especially with greenify app)
Sent from my Nexus 7 using XDA Premium HD app
3) Cookies_Cream-1.3.1
Tablet ui...... yes ( built in as standard )
DPI changer ...yes ( 160 dpi native )
Size custom nav bar ....yes
Speed....... ok
Response ... ok
Before Gapps
First reboot 560mb
Second reboot 560mb
Cache wipe reboot 560mb
Subsequent reboots 560mb ( stable )
Although a memory hungry beast this rom is optimised for the n7 resolution AS STANDARD, you get full true tablet ui, AND with the PARANOID ANDROID framework, it is ultimately compatible with any app at any resolution, and best of all it all works!! no bugs that i can see, although memory use is very high at least it is quite stable before gapps.
If you want the full tablet experience out of the box then consider this.
I have not tried a memory test after gapps, 560 was too high for me without gapps let alone with
4) BeatMod_CrystalClear_v2.3.zip
Tablet ui...... yes
DPI changer ...no
Size custom nav bar ....yes
Speed....... good
Response ... good
Gapps are included
First reboot 480mb
Second reboot 4100mb
Cache wipe reboot 400mb
Subsequent reboots 440mb ( NOT STABLE can go 500mb+ )
being pure CM10 this one is very different in style to the AOKP based roms, but is almost identical to smooth rom in terms of memory usage, although less responsive, on the up side is packed full os sound enhancing mods and an upgraded bravia engine for video
the rest are in no particular order
gsw5700 said:
What's more interesting is that identical apps on the galaxy S3 take up 2-3 times more memory. 1GB is fine on the N7 but you have to do a lot of fiddling to get the S3 running with 1GB. Must be down to the Tegra architecture. Smooth 5 runs great on the N7 (especially with greenify app)
Sent from my Nexus 7 using XDA Premium HD app
Click to expand...
Click to collapse
jesus am wandering how 512k devices ever ran !!!, android MUST have gotten a lot more bloaty since the 2.x days, otherwise nothing would have worked !!!
jubei_mitsuyoshi said:
jesus am wandering how 512k devices ever ran !!!, android MUST have gotten a lot more bloaty since the 2.x days, otherwise nothing would have worked !!!
Click to expand...
Click to collapse
You got it! There's a huge difference between the gingerbread days and now, i remember when my droid eris would use 200 megs of ram for the OS, now.....its a lot more. Why do you think new devices are getting 2gigs of ram, I'm guessing key lime pie will only use more and more memory to give us a better experience
Sent from my Nexus 7 using xda app-developers app
Triscuit said:
You got it! There's a huge difference between the gingerbread days and now, i remember when my droid eris would use 200 megs of ram for the OS, now.....its a lot more. Why do you think new devices are getting 2gigs of ram, I'm guessing key lime pie will only use more and more memory to give us a better experience
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Hmm have to take your word on better experience having just come to android.
PRIME runs at 266mb without gapps, thats a bloody good number for android, just needs the bugs fixed and a minimal/mico ( just playstore functionality, without the paid service ) gapps integrated so all the settings etc function, then we are talking as good as it gets with android.
Generally if you want something doing do it yourself but in this case am in the middle of becoming proficient in c/c++ ( again , its amazing when buried in hardware, pcb design, spice sims, matlab etc etc that one can just forget how to code, i always thought it would be like riding a bike WRONG! ) so learning java from scratch is out for at least 6 months, am very much in hope that PRIME does it for me ,
Before you go any further you should define exactly what you mean by "memory usage".
I challenge you to correlate your "memory usage" statistic to anything you can find in /proc/meminfo.
Go ahead, give it a try.
In any modern OS - including Android - 100% of DRAM is in use. The only thing which remains is some quibbling about whether you should give up file cache space for process memory space or kernel private memory, and the answer to those questions always depend on the nature of the workload.
The whole of dalvik is built on top of native shared libraries that are substantially smaller than the totality of shared libraries present in (let's say) a recent Linux distro. They can be memory mapped in copy-on-write or read-only fashion to a large number of process spaces, and so in fact it is a strategy of the "system_server" process to preload most of them. That way new activities spring to life quickly, rather than being required to demand-load and link everything from scratch.
Bottom line: it is an intentional strategy of android to "use up memory" right from the get-go. Most of that "used memory" is shared libraries that are mapped into activities as they come and go.
So, would I want to run engineering applications that require 800 MB of heap space on an android OS tablet with 1 GB of RAM? The answer is clearly "no" in that case, but mostly because Android devices are not targeted for that kind of work.
For comparison, BTW, my Win 7 x64 box that is nearly bare of applications (I only use it as a VM host) needs 1 GB of committed page space to sit there and do nothing. Android isn't doing so badly in comparison.
cheers
bftb0 said:
Before you go any further you should define exactly what you mean by "memory usage".
I challenge you to correlate your "memory usage" statistic to anything you can find in /proc/meminfo.
Go ahead, give it a try.
In any modern OS - including Android - 100% of DRAM is in use. The only thing which remains is some quibbling about whether you should give up file cache space for process memory space or kernel private memory, and the answer to those questions always depend on the nature of the workload.
The whole of dalvik is built on top of native shared libraries that are substantially smaller than the totality of shared libraries present in (let's say) a recent Linux distro. They can be memory mapped in copy-on-write or read-only fashion to a large number of process spaces, and so in fact it is a strategy of the "system_server" process to preload most of them. That way new activities spring to life quickly, rather than being required to demand-load and link everything from scratch.
Bottom line: it is an intentional strategy of android to "use up memory" right from the get-go. Most of that "used memory" is shared libraries that are mapped into activities as they come and go.
So, would I want to run engineering applications that require 800 MB of heap space on an android OS tablet with 1 GB of RAM? The answer is clearly "no" in that case, but mostly because Android devices are not targeted for that kind of work.
For comparison, BTW, my Win 7 x64 box that is nearly bare of applications (I only use it as a VM host) needs 1 GB of committed page space to sit there and do nothing. Android isn't doing so badly in comparison.
cheers
Click to expand...
Click to collapse
Hmmm
Well lets start with the last first, i run a heavily customized ( rt7 lite, wintoolkit, buclean ) windows 7 ( EE edition which i mastered ) on a asus g15w i7 8 gb geforce 470 , with all drivers in, on full aero , <>560mb mem usage for the system, can go down to 500 if you disable the nvidia startups and services but you lose the nvidia controll panel.
I totally take the point that memory usage in modern multi-core systems is friggin complex, obviously these memory stats are not supposed to be definitive in any way, but given all the tests are run on the same hardware with the same inbuilt prog they can be used as COMPARATIVE results, ie you can say rom x is more efficient than rom y given they do the same thing but with different memory results.
By definition any code abstraction away from 1's and zeros makes that code less efficient, an entire graphical os can fit into 1.8mb if written in x86 ASM, same code becomes <>20mb in C, 25mb in C++, 80mb+ in vm bytecode, the same pattern can be found in mem usage.
Any virtual machine no matter how clever ( and dalvik is bloody clever ) is a glorified interpreter, hence slower ( by a few factors ) than c/c++, which is itself slower by a few factors than ASM.
My opinion on caching is DONT, unless someone comes up with a really psychic piece of code that can for real predict the chaotic needs of the average human, all caching algorithms are just guessing, and do i trust the system to free up all that memory in time when something ( as you say ) calls up a massive heap or worst maloc's it direct, errrr no.
But thats just an opinion, am totally willing to recant if i see evidence and accurate benchmarks to the contrary ( and you seem to know your stuff, so if im way of the mark please enlighten me ! )
*Before I begin, I must warn everyone that I am a newly registered XDA-Developers user, therefore I am technically a noob.
*English is NOT my first language/mother tongue. If some of the the questions posted below are not understandable, feel free to ask me and I will try my best to rephrase what I said. More information is added below every question for the same one.
*I have read the Forum rules, and did my best to comply with them. Hopefully this does not violate any of the aforementioned rules. If there is such a thing, I will immediately remove any parts/the entire thread.
*As stated above, I did use the search tool, however I did not find any similar thread to this one, hence the reason of opening one.
*Not really experienced with using forum tools, you'll notice the lack of formatting here.
*Summer just started, and with that I have a lot of free time that I wish to devote that time in increasing my knowledge of Android and (hopefully) start being useful with developing something.
1.1. What programming language is required to know when developing an app?
-I've been informed that most apps are developed in Java for Android, however I am curious as to whether or not I can program in C++ as well.
1.2.What programming language(s) is/are required to know when building a ROM from source?
-Many OS's are developed in different programming languages, does this apply to Android as well?
1.3. What IDE is best for developing an app?
-I am referring to the Integrated Development Environment. Which is best for Android?
2.When building from source, is it necessary to have a distribution of Linux running on your computer, or can this be done on Windows/OSX as well?
-Installing Ubuntu on my PC is problematic. For whatever reason, it can not initialize the drivers for my GTX 560 SE, thus rendering my computer unusable. So as stated, can't I work with Windows, or do I have to be forced to buy a new machine?
3.What programs/files are required to install or download to create an environment for building from source?
-IDE's, libraries etc.
4.What system requirements are needed?
-If I do need to buy a new computer, what are the minimum requirements to work freely, as in without much stuttering when compiling?
5.Which custom recovery better suits the needs of our SGM?
TWRP or CWMR? Or a third one I have yet to familiarize myself with?
6.What is the current highest version of kernel working on our device?
7.Does our SGM have a custom ROM flash counter?
-In the Play Store, Chainfire has an app that resets the number of times you have flashed a custom ROM. Does our device have this?
8.What group/team(s) are currently building Android versions from source for our SGM?
-I do know of AndroidARMV6, any other team I should know of?
9.What counts as a "custom ROM"?
-Can I take a build from rohan007, strap some apps in it, change the bootanimation and call it my own? (with permission of course)
10.Does everyone encounter volume problems when flashing custom ROMs?
-On a stock ROM, the volume on the headphones is perfect, however on every custom ROM I have flashed, the sound is too loud. The volume rocker goes too high. Is this on purpose?
11.What does porting mean for ROMs and games?
-Simply put, with permission from the original developer, porting a ROM and a game means making it available for our device. But what are the limitations of this? I certainly can not take NFS Shift, scale down the textures and post it, right?
12.Does every custom ROM drain battery life on a huge scale?
-For every 20 min, 5% of my battery is drained, while on stand-by. I'm not even going to talk about the drain when actually using the device. I can't make it operate more that 2 hours without it dying. This problem is not present when having a stock ROM.
13.How is a custom kernel installed?
-Is it via ODIN or custom recovery? Or does it depend on what the file actually is?
14.What is the output power of our 3.5mm headphone jack?
-If I plug my 2 small desktop speakers, the phone just hangs, while, for example, my cousins IP5 has no issue with having 300W 2 speakers plugged in to it. What is the limit? I take it it is very small.
15.What does GPU rendering mean?
-I've noticed a few custom ROMs being able to use GPU rendering. Does it mean it renders the UI with the GPU instead of the CPU to give a smoother experience? If so, does this impact battery life?
16.What is the limit of an SD card on our phone?
-In terms of storage and speed transfer.
17.What is the highest overclock recommended for the SGM?
-I think it is around 750MHz, but I've seen ROMs pushing our phone up to 864MHz, with no users reporting fried phones. Does it even matter if the voltage is not changed?
18.What is our GPU?
-You read it correctly. I mean this as in is it a standalone chip or is it integrated? Can you also provide information on how fast is exactly our Adreno 200?
18.1. Can we overclock our GPU?
-Like on PCs, can we overclock our GPU to gain more performance? Has this been done before, and how successful is it?
18.2. Do different drivers exist for our GPU?
18.3. If so, does using them make a difference in terms of performance?
19.Do different (if any) drivers exist for other hardware located on our phone?
-Like our GPU, do we have individual drivers for Wi-Fi, Bluetooth etc.? If so, does using them make a difference?
That is all, and thank you to whoever can answer at least some of these.
5.Which custom recovery better suits the needs of our SGM?
TWRP or CWMR? Or a third one I have yet to familiarize myself with?
At the moment TWRP is not fully working, better choose CWMR.
A third one will be RZ Recovery, you can find it in "original development" thread.
9.What counts as a "custom ROM"?
-Can I take a build from rohan007, strap some apps in it, change the bootanimation and call it my own? (with permission of course)
Try to change as much as possible.
10.Does everyone encounter volume problems when flashing custom ROMs?
-On a stock ROM, the volume on the headphones is perfect, however on every custom ROM I have flashed, the sound is too loud. The volume rocker goes too high. Is this on purpose?
Yes
This is present on cm7.2/9/10/10.1
On every Stock ROM or custom stock ROM headphones sound is limited by samsung.
I don't take this as a problem... i think it's a plus
12.Does every custom ROM drain battery life on a huge scale?
-For every 20 min, 5% of my battery is drained, while on stand-by. I'm not even going to talk about the drain when actually using the device. I can't make it operate more that 2 hours without it dying. This problem is not present when having a stock ROM.
No
There are Rom's with huge battery drain, and there are others that can make your phone last for 2-3 days
13.How is a custom kernel installed?
-Is it via ODIN or custom recovery? Or does it depend on what the file actually is?
Via Custom Recovery.
16.What is the limit of an SD card on our phone?
-In terms of storage and speed transfer.
32GB max storage/ uhs-1 max speed
I have a class 10 8GB Kingston and it's perfect
17.What is the highest overclock recommended for the SGM?
-I think it is around 750MHz, but I've seen ROMs pushing our phone up to 864MHz, with no users reporting fried phones. Does it even matter if the voltage is not changed?
The highest indeed is 864Mhz but i never heard anyone running at such high speed. Mine is at 729Mhz, that's 20% overclock...and never had problems like freezing or random rebooting.
Thanks for the answers XDRdaniel.
About the sound output, I think this should be considered a flaw, why push the jack above it's limit, all you get is defected sound, no matter what headphones you are using.
And the clarity also is worse on custom ROMs. Whether this has something to do with my ears, the sound is not clear as having a stock ROM.
Why not take the stock music app with its optimized equalizer and install it on CM for example. Is it copyrighted or something?
Hopefully, other users will answer the rest of my questions.
Reaper's Scythe said:
Thanks for the answers XDRdaniel.
About the sound output, I think this should be considered a flaw, why push the jack above it's limit, all you get is defected sound, no matter what headphones you are using.
And the clarity also is worse on custom ROMs. Whether this has something to do with my ears, the sound is not clear as having a stock ROM.
Why not take the stock music app with its optimized equalizer and install it on CM for example. Is it copyrighted or something?
Hopefully, other users will answer the rest of my questions.
Click to expand...
Click to collapse
It's not about the music player. The rom is the one that has volume boost. It's not that simple
also if you are using a CM based rom i recomend you to use this audio mod.
1.1. What programming language is required to know when developing an app?
-I've been informed that most apps are developed in Java for Android, however I am curious as to whether or not I can program in C++ as well.
A > Java, and sometimes C++. But Java is better.
1.2.What programming language(s) is/are required to know when building a ROM from source?
-Many OS's are developed in different programming languages, does this apply to Android as well?
A > No programming language needed, except when you want to add features to kernels, base, etc. Mostly Java and C++ are needed
1.3. What IDE is best for developing an app?
-I am referring to the Integrated Development Environment. Which is best for Android?
A > Eclipse IDE
2.When building from source, is it necessary to have a distribution of Linux running on your computer, or can this be done on Windows/OSX as well?
-Installing Ubuntu on my PC is problematic. For whatever reason, it can not initialize the drivers for my GTX 560 SE, thus rendering my computer unusable. So as stated, can't I work with Windows, or do I have to be forced to buy a new machine?
A > No, building can only done using Linux. Try using another distro.
3.What programs/files are required to install or download to create an environment for building from source?
-IDE's, libraries etc.
A > Many libraries needed, you can search google for it.
4.What system requirements are needed?
-If I do need to buy a new computer, what are the minimum requirements to work freely, as in without much stuttering when compiling?
A> A power PC, with 64 Bit architecture. Around 10 GB RAM, more is better. Also, a fast internet speed is needed.
5.Which custom recovery better suits the needs of our SGM?
TWRP or CWMR? Or a third one I have yet to familiarize myself with?
A > TWRP isn't stable yet. Use CWMR
6.What is the current highest version of kernel working on our device?
A > 2.37.6
7.Does our SGM have a custom ROM flash counter?
-In the Play Store, Chainfire has an app that resets the number of times you have flashed a custom ROM. Does our device have this?
A > No
8.What group/team(s) are currently building Android versions from source for our SGM?
-I do know of AndroidARMV6, any other team I should know of?
A > Team GingerDX or whatever they call it. They build GingerDX ROM based on Gingerbread.
9.What counts as a "custom ROM"?
-Can I take a build from rohan007, strap some apps in it, change the bootanimation and call it my own? (with permission of course)
A > Do some theming. To make it unique.
10.Does everyone encounter volume problems when flashing custom ROMs?
-On a stock ROM, the volume on the headphones is perfect, however on every custom ROM I have flashed, the sound is too loud. The volume rocker goes too high. Is this on purpose?
A > No, sound is perfect for me, basically stock ROM music player have it's own equalizer. BUT, if you do a little more tweaking sound will be perfect.
11.What does porting mean for ROMs and games?
-Simply put, with permission from the original developer, porting a ROM and a game means making it available for our device. But what are the limitations of this? I certainly can not take NFS Shift, scale down the textures and post it, right?
A > No, you're already right. But for NFS, i think you can't.
12.Does every custom ROM drain battery life on a huge scale?
-For every 20 min, 5% of my battery is drained, while on stand-by. I'm not even going to talk about the drain when actually using the device. I can't make it operate more that 2 hours without it dying. This problem is not present when having a stock ROM.
A > Well, it's ROM problem or hardware problem. I have CM7.2 and the battery stand for 2 hours for browsing + music, and 5 hours for listening music, OR 24 Hours without being used.
13.How is a custom kernel installed?
-Is it via ODIN or custom recovery? Or does it depend on what the file actually is?
A > Some uses recovery some uses ODIN.
14.What is the output power of our 3.5mm headphone jack?
-If I plug my 2 small desktop speakers, the phone just hangs, while, for example, my cousins IP5 has no issue with having 300W 2 speakers plugged in to it. What is the limit? I take it it is very small.
A > It's jack limitation.
15.What does GPU rendering mean?
-I've noticed a few custom ROMs being able to use GPU rendering. Does it mean it renders the UI with the GPU instead of the CPU to give a smoother experience? If so, does this impact battery life?
A > Yeah, sorta like that. No it doesn't impact battery life.
16.What is the limit of an SD card on our phone?
-In terms of storage and speed transfer.
A > Storage 32 GB. Speed 10 MBs.
17.What is the highest overclock recommended for the SGM?
-I think it is around 750MHz, but I've seen ROMs pushing our phone up to 864MHz, with no users reporting fried phones. Does it even matter if the voltage is not changed?
A > This is what make phone unique, some phone can handle 800 and more Mhz, some only handle 700 and more Mhz.
18.What is our GPU?
-You read it correctly. I mean this as in is it a standalone chip or is it integrated? Can you also provide information on how fast is exactly our Adreno 200?
A > Intergrated. Not really fast, search for google for the answer.
18.1. Can we overclock our GPU?
-Like on PCs, can we overclock our GPU to gain more performance? Has this been done before, and how successful is it?
A > It can't.
18.2. Do different drivers exist for our GPU?
A > No, only patched drivers exist.
18.3. If so, does using them make a difference in terms of performance?
A > It does on some Android version.
19.Do different (if any) drivers exist for other hardware located on our phone?
-Like our GPU, do we have individual drivers for Wi-Fi, Bluetooth etc.? If so, does using them make a difference?
A > Only if you source build a ROM, you can change the drivers. Drivers are exist, like WiFi driver, etc. Yes, it's make a huge or small difference.
F4uzan said:
1.1. What programming language is required to know when developing an app?
-I've been informed that most apps are developed in Java for Android, however I am curious as to whether or not I can program in C++ as well.
A > Java, and sometimes C++. But Java is better.
1.2.What programming language(s) is/are required to know when building a ROM from source?
-Many OS's are developed in different programming languages, does this apply to Android as well?
A > No programming language needed, except when you want to add features to kernels, base, etc. Mostly Java and C++ are needed
1.3. What IDE is best for developing an app?
-I am referring to the Integrated Development Environment. Which is best for Android?
A > Eclipse IDE
2.When building from source, is it necessary to have a distribution of Linux running on your computer, or can this be done on Windows/OSX as well?
-Installing Ubuntu on my PC is problematic. For whatever reason, it can not initialize the drivers for my GTX 560 SE, thus rendering my computer unusable. So as stated, can't I work with Windows, or do I have to be forced to buy a new machine?
A > No, building can only done using Linux. Try using another distro.
3.What programs/files are required to install or download to create an environment for building from source?
-IDE's, libraries etc.
A > Many libraries needed, you can search google for it.
4.What system requirements are needed?
-If I do need to buy a new computer, what are the minimum requirements to work freely, as in without much stuttering when compiling?
A> A power PC, with 64 Bit architecture. Around 10 GB RAM, more is better. Also, a fast internet speed is needed.
5.Which custom recovery better suits the needs of our SGM?
TWRP or CWMR? Or a third one I have yet to familiarize myself with?
A > TWRP isn't stable yet. Use CWMR
6.What is the current highest version of kernel working on our device?
A > 2.37.6
7.Does our SGM have a custom ROM flash counter?
-In the Play Store, Chainfire has an app that resets the number of times you have flashed a custom ROM. Does our device have this?
A > No
8.What group/team(s) are currently building Android versions from source for our SGM?
-I do know of AndroidARMV6, any other team I should know of?
A > Team GingerDX or whatever they call it. They build GingerDX ROM based on Gingerbread.
9.What counts as a "custom ROM"?
-Can I take a build from rohan007, strap some apps in it, change the bootanimation and call it my own? (with permission of course)
A > Do some theming. To make it unique.
10.Does everyone encounter volume problems when flashing custom ROMs?
-On a stock ROM, the volume on the headphones is perfect, however on every custom ROM I have flashed, the sound is too loud. The volume rocker goes too high. Is this on purpose?
A > No, sound is perfect for me, basically stock ROM music player have it's own equalizer. BUT, if you do a little more tweaking sound will be perfect.
11.What does porting mean for ROMs and games?
-Simply put, with permission from the original developer, porting a ROM and a game means making it available for our device. But what are the limitations of this? I certainly can not take NFS Shift, scale down the textures and post it, right?
A > No, you're already right. But for NFS, i think you can't.
12.Does every custom ROM drain battery life on a huge scale?
-For every 20 min, 5% of my battery is drained, while on stand-by. I'm not even going to talk about the drain when actually using the device. I can't make it operate more that 2 hours without it dying. This problem is not present when having a stock ROM.
A > Well, it's ROM problem or hardware problem. I have CM7.2 and the battery stand for 2 hours for browsing + music, and 5 hours for listening music, OR 24 Hours without being used.
13.How is a custom kernel installed?
-Is it via ODIN or custom recovery? Or does it depend on what the file actually is?
A > Some uses recovery some uses ODIN.
14.What is the output power of our 3.5mm headphone jack?
-If I plug my 2 small desktop speakers, the phone just hangs, while, for example, my cousins IP5 has no issue with having 300W 2 speakers plugged in to it. What is the limit? I take it it is very small.
A > It's jack limitation.
15.What does GPU rendering mean?
-I've noticed a few custom ROMs being able to use GPU rendering. Does it mean it renders the UI with the GPU instead of the CPU to give a smoother experience? If so, does this impact battery life?
A > Yeah, sorta like that. No it doesn't impact battery life.
16.What is the limit of an SD card on our phone?
-In terms of storage and speed transfer.
A > Storage 32 GB. Speed 10 MBs.
17.What is the highest overclock recommended for the SGM?
-I think it is around 750MHz, but I've seen ROMs pushing our phone up to 864MHz, with no users reporting fried phones. Does it even matter if the voltage is not changed?
A > This is what make phone unique, some phone can handle 800 and more Mhz, some only handle 700 and more Mhz.
18.What is our GPU?
-You read it correctly. I mean this as in is it a standalone chip or is it integrated? Can you also provide information on how fast is exactly our Adreno 200?
A > Intergrated. Not really fast, search for google for the answer.
18.1. Can we overclock our GPU?
-Like on PCs, can we overclock our GPU to gain more performance? Has this been done before, and how successful is it?
A > It can't.
18.2. Do different drivers exist for our GPU?
A > No, only patched drivers exist.
18.3. If so, does using them make a difference in terms of performance?
A > It does on some Android version.
19.Do different (if any) drivers exist for other hardware located on our phone?
-Like our GPU, do we have individual drivers for Wi-Fi, Bluetooth etc.? If so, does using them make a difference?
A > Only if you source build a ROM, you can change the drivers. Drivers are exist, like WiFi driver, etc. Yes, it's make a huge or small difference.
Click to expand...
Click to collapse
Thank you so much, I guess that's all. This thread can be closed now
I have open this thread for all(me included)user with no idea about ART,so here are some infos about it,what is ART,how does it work,pro+cons.
Maybe its helpfull for some peeps here.Source: Android Police
Link p1
Link p2
-------------
Part 1:
It's fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven't aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That's why Google's developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.
What Is ART?
ART, which stands for Android Runtime, handles app execution in a fundamentally different way from Dalvik. The current runtime relies on a Just-In-Time (JIT) compiler to interpret bytecode, a generic version of the original application code. In a manner of speaking, apps are only partially compiled by developers, then the resulting code must go through an interpreter on a user's device each and every time it is run. The process involves a lot of overhead and isn't particularly efficient, but the mechanism makes it easy for apps to run on a variety of hardware and architectures. ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation. By removing the need to spin up a new virtual machine or run interpreted code, startup times can be cut down immensely and ongoing execution will become faster, as well.
At present, Google is treating ART as an experimental preview, something for developers and hardware partners to try out. Google's own introduction of ART clearly warns that changing the default runtime can risk breaking apps and causing system instability. ART may not be completely ready for prime time, but the Android team obviously feels like it should see the light of day. If you're interested in trying out ART for yourself, go to Settings -> Developer options -> Select runtime. Activating it requires a restart to switch from libdvm.so to libart.so, but be prepared to wait about 10 minutes on the first boot-up while your installed apps are prepared for the new runtime. Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable.
How Much Better Is It?
For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn't representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM's big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.
What Are The Compromises?
There are a couple of drawbacks to using AOT compilation, but they are negligible compared to the advantages. To begin with, fully compiled machine code will usually consume more storage space than that of bytecode. This is because each symbol in bytecode is representative of several instructions in machine code. Of course, the increase in size isn't going to be particularly significant, not usually more than 10%-20% larger. That might sound like a lot when APKs can get pretty large, but the executable code only makes up a fraction of the size in most apps. For example, the latest Google+ APK with the new video editing features is 28.3 MB, but the code is only 6.9 MB. The other likely notable drawback will come in the form of a longer install time for apps - the side effect of performing the AOT compilation. How much longer? Well, it depends on the app; small utilities probably won't even be noticed, but the more complex apps like Facebook and Google+ are going to keep you waiting. A few apps at a time probably won't bother you, but converting more than 100 apps when you first switch to ART is a serious test of patience. This isn't entirely bad, as it allows the AOT compiler to work a little harder to find even more optimizations than the JIT compiler ever had the opportunity to look for. All in all, these are sacrifices I'm perfectly happy to make if it will bring an otherwise more fluid experience and increased battery life.
Overall, ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. The improvements are likely to be pretty amazing while the drawbacks should be virtually undetectable. There is a lot more than I could cover in just this post alone, including details on how it works, benchmarks, and a lot more. I'll be diving quite a bit deeper into ART over the next few days, so keep an eye out!
---------------------------------------------
Part 2 in next post.....
Part 2
---------
By now you've probably heard about ART and how it will improve the speed and performance of Android, but how does it actually perform today? The new Android Runtime promises to cut out a substantial amount of overhead by losing the baggage imposed by Dalvik, which sounds great, but it's still far from mature and hasn't been seriously optimized yet. I took to running a battery of benchmarks against it to find out if the new runtime could really deliver on these high expectations. ART is definitely showing some promise, but I have to warn you that you probably won't be impressed with the results you'll see here today.
Reality Check
Let's be honest, benchmarking apps tend to be inaccurate and unreliable, often giving wildly varying results even when run in precisely identical situations. However, they are the only option available for recording meaningful and measurable values on performance. Further, since most popular benchmarks are built on the NDK (Native Development Kit), they won't gain any benefit from running under ART. Despite these limitations, there are some interesting and unexpected results that help us learn a little more about the current state of performance.
How The Benchmarks Were Run
Each benchmark was run at least 4 times on a completely stock Nexus 5 (it isn't even rooted) with both Dalvik and ART. To ensure there was no interference from apps at startup, a minimum of 5 minutes was given after a reboot before any tests were run. In addition to the 6 benchmarking apps listed below, I also tried 2 browser benchmarks (SunSpider & BrowserMark) in Chrome, but neither displayed significantly different scores. So, let's get to the results.
Linpack for Android
One of the key factors in getting good test results is knowing that the tools are measuring the right thing. While many of the benchmark apps target the NDK, a few stick to the SDK. The first and most consistent among them is Linpack for Android, a port of the already popular benchmarking app used throughout numerous computing platforms. It produces a score by performing a series of calculations on floating point numbers. I think this is an obvious choice after reading the description, "This test is more a reflection of the state of the Android Dalvik Virtual Machine than of the floating point performance of the underlying processor." Thanks to ART, scores are 10%-14% higher than they would be with Dalvik. Not too shabby…
Real Pi Benchmark
Calculating digits of Pi is another popular way of stressing a processor, and particularly suitable because most methods stick to integer calculations and avoid floating-point math entirely. Along with Linpack, this gives us coverage of both basic mathematical operations. On top of it, Real Pi happens to use native code to perform the AGM+FFT formula, but uses Java for Machin's formula. On the native side, ART came out about 3.5% faster, probably due to interface optimizations rather than mathematical performance. More importantly, testing with the java code turned out to be 12% faster. (link) Note: in this test, lower numbers are better.
Quadrant Standard
The previous tests are highly specific to mathematical performance, so it's time to branch out to test more of the system. Both Linpack and Real Pi show some positive improvement with ART, but Quadrant gave a result that borders on the amazing, perhaps even too good. The CPU score is off the charts for ART, almost doubling that of Dalvik, which is substantially better than even the most optimistic estimates we've heard so far... While tests for I/O, 2D, and 3D rendering show fairly negligible differences, Dalvik does take an oddly high 9% advantage in the memory test.
3D Mark
I was leery of using a benchmarking app that clearly focuses on the NDK, as it theoretically shouldn't be affected very much by ART. However, as the tests were run, an interesting pattern emerged where the Dalvik runtime repeatedly held a slight advantage. It's difficult to attribute a reason for Dalvik to do better here, but I'm open to theories.
AnTuTu Benchmark
Breaking performance down even further, AnTuTu helps to expose a pattern. It's increasingly clear that ART is making significant strides with floating-point operations, but doesn't usually turn out huge gains for integers. A strong showing in "RAM Operation" also hints at better use of caching as opposed to just raw memory I/O. These high scores indicate areas where the Dalvik virtual machine was probably very expensive, causing more extensive overhead. The other results weren't particularly remarkable except for the Storage I/O, which might suggest a couple of specific optimizations. One significantly low score appears for UX Dalvik, but it's not clear what AnTuTu is measuring, so this may not be particularly relevant.
CF-Bench
For the ultimate in number production, Chainfire's own benchmark tool takes out a lot of the guesswork by performing tests built on both the SDK and NDK. Again, native code displays a small but curious advantage on Dalvik. Here we can see the integer calculations are swinging back towards Dalvik, as well. Mostly confirming the pattern, floating-point operations demonstrate a significant speed gain, this time in the 23%-33% range.
Other Interesting Measurements
Measuring the first boot after switching runtimes isn't your typical test, no doubt, but the time it takes is quite striking. I wanted to record just how long it took to complete both the App Optimization step and then the total time to actually reach the unlock screen. When I ran this test, I had 149 apps installed.
The Other Stuff
While numbers can be helpful, they don't tell the full story. Benchmarks usually push the hardware to work as hard as possible for a few seconds, then switch to a new test that does the same thing. Sadly, this ignores details that aren't easily measured. I don't have a good way to measure the smarter timing of memory management (especially garbage collection) or better handling of multiple threads. While I can't show numbers for these things, I can demonstrate them. The classic test for a browser simply requires flinging the page as fast as possible and watching it try to keep up. After stress testing Chrome for Android with the mobile version of David's gigantic HTC One review, it turns out that even the supercharged SoC of the Nexus 5 can't quite keep up while running on Dalvik… ART, on the other hand, never lost a pixel. Take a look for yourselves.Videos below.
Fast scrolling with dalvik: http://youtu.be/JGyktLPvORU
with ART: http://youtu.be/L9lpCssSdMc
To be fair, switching to the desktop version and giving a single fling will easily send you into blank screen territory, but it's still obvious that the renderer catches up faster on ART than on Dalvik. When more optimizations are in place, maybe we won't be far off from flawless scrolling even in the desktop version. For another demonstration, a user by the name of spogbiper has posted his own side-by-side comparison with two Nexus 7s. The one running ART seems to be more responsive.
Summary And Conclusions
The numbers and the videos together paint a picture of where ART stands today. It will definitely make a difference, but its current incarnation just hasn't matured enough to deliver significant gains. Floating-point calculations and basic responsiveness are obviously reaping the benefits of the new runtime, but that's about it. There's little or no overall improvement for integer calculations, most regular code execution, or much of anything else. In fact, it looks like gamers would be better served by sticking to Dalvik, for now.
Why aren't the benchmarks blowing us away? If I were to make a guess, it's probably because the first goal in developing ART was to make sure it was functional and stable before the heavy optimizations came into effect. If that's the case, there is probably quite a bit of code for error-checking and logging just to ensure everything is operating as it should, which might even be responsible for more overhead than we had with Dalvik. Even in the places where ART doesn't outperform Dalvik, the numbers tend to remain reasonably close. As subsequent versions of the runtime emerge from Mountain View, we should expect to see the performance gap growing wider as ART pulls ahead.
Now for the real question: is it worth switching to ART right now? Google obviously isn't recommending it for regular users, and I tend to agree. While ART seems very solid and I feel like responsiveness is better - possibly just the placebo effect - there are still circumstances where it is unstable and causes apps to crash. If there is even a single instance where you have to switch back to Dalvik to get an app to run correctly, that inconvenience far outweighs the minimal performance gain you might have had. Once I've finished this series, I will probably stick to Dalvik for the remainder of KitKat; and I imagine most people will be better served by doing the same.
Introducing ART from: source.android.com
ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.
Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.
Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART (libart.so). A device can be built using either or both. (You can dual boot from Developer options if both are installed.)
The dalvikvm command line tool can run with either of them now. See runtime_common.mk. That is included from build/target/product/runtime_libdvm.mk or build/target/product/runtime_libdvm.mk or both.
A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/core_minimal.mk or build/target/product/core_base.mk.
Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default:
PRODUCT_RUNTIMES := runtime_libdvm_default
PRODUCT_RUNTIMES += runtime_libart
------------------------------------------------------------
MANY GREEEETZ+STAY ADDICTED!!!!
Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
velosa said:
Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.
-CALIBAN666- said:
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.
Click to expand...
Click to collapse
Thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
thank you very much for your work about ART presentation ! very nice and perfect ! :good:
conclusion : don not use ART for the moment on CM11 ! ok ! wait more stability ...
i've downloaded gapps kk from cr3pt thread for cm 11, while i'm waiting for more stability i wanna ask you if they are art compatible.
Best presentation of ART!
When the gapps are odexed than yes.
STAY ADDICTED,GREEEETZ!!!
Hi everyone, this is a guide based on my personal tests, which I have the pleasure to share with the whole community, for experienced users and not. Regardless of whether you prefer to use a MIUI stock or a custom ROMs, these are a series of tricks, Tweaks, passages, let's call them what we want, to get the maximum in terms of battery life, without sacrificing performance. First of all, we talk mainly to have the better experience for MIUI and PRINCIPALLY for ROOTED users, and custom ROMs too. No rooted users cannot expect miracles because there are modifications that mainly affect the entire operating system. I also hoped to find the Holy Grail, but unfortunately it still hasn't happened.
Anyway,: If you want to use a MIUI (preferably GLOBAL, I will explain later why this is the case); the first thing I recommend in addition to a backup (just in case), it's a pretty safe Debloat using the complete Saki tool:
https://saki-eu.github.io/XiaomiADBFastbootTools/
After giving our device a nice cleanup from Bloatware (obviously you choose which ones to remove or not, personally I removed almost all of them leaving only Gallery, Phone and Messages without any problem), the best part comes, and that is to apply all the settings for a better user experience in every aspect. The MIUI is obviously not optimized as a custom ROM, so we should do it ourselves. Personally I am a root user, so first of all I flashed Evira Kernel and Magisk (with which I am wonderfully) and put modules that I personally recommend: LKT (or others similar modules), Syconfig Patcher (they are the ones that interest us), but of course the appearance rooting is optional.
But back to optimization; for each application that we will install, we will have to configure its type of activity in the background based on how much you want the app to act in the background. For example, the "MIUI Calculator" app, which I almost never use, will have set "limit app functions", otherwise applications that we will use more often will suffice "MIUI optimization", such as "Youtube", and what more important, for apps for which notification is essential (such as Whatsapp or Gmail), remove the limitations.
But it's not over. Write in the settings menu "change system settings", then a list will open with all the apps we have installed. Clicking on one of them, a menu will open, where clicking on "battery and performance", we will choose whether to put the limitations in the background or not, same speech as before, limit everything that is not necessary, inverse speech obviously goes for app important to us (gmail whats etc), which we will leave free to act in the background.
Still in the "battery and performance" menu, click on "battery optimization" and optimize everything you can, except as usual, the apps you don't want to be limited as in the previous two steps.
Now we can activate the "Battery saving" mode, which will obviously work on the whole system, except for all the apps that we have NOT optimized before. They will absolutely not be touched. (A nice break of *** optimize the MIUI , Doh!)
Remember that at the beginning of the guide I told you "better to focus on the global rather than the ROM developer?" well, using a third-party tool like Kernel auditor (personally I use EX Kernel Manager with which I am wonderfully), in the dashboard the developer rom had higher CPU peaks than the Global.Il that involved higher consumption. And it is a tool like this "Ex Kernel Manager etc" that we will now configure.
Step 1 Configure the Governor.
The mode and the speed with which the processor passes from the maximum frequency to the minimum one is regulated by the so-called * "Governor"
There are more than 100 different types of Governor for kernel, more or less different; but not all Governors are present in the Kernels. In case you are using Evira Kernel, my advice is to set the CPU to the "Alucardsched" Governor which offers an excellent compromise between performance and battery life.
EDIT: Recently tested zzmove gov with Evira Kernel: little performance is lost compared to alucardsched, but the battery benefits. Personally i have chosen profile 3 (ybatex).
Step 2 I / O scheduler
It is precisely a program in the form of an algorithm which, given a set of requests for access to a resource, establishes a temporal order for the execution of such requests, privileging those that respect certain parameters, so as to optimize the access to this resource and thus allow the completion of the desired service / instruction or process. In this case, I recommend setting it to noop or Zen, for an approach closer to the battery.
In the GPU section, if you don't use particularly heavy games, (personally I play every now and then in clash royale and I don't have any kind of lag at all) you can also set up your own governor here, setting one like Powersave, but in any case this is completely subjective .
Once everything is set up, all that remains is to talk about the last aspect,
the Doze.
Originally introduced with Android Marshmallow, it allows applications and various activities in the background to "sleep" when the device is screen off. Of course over time it has been increasingly perfect, which is why: In a Stock MIUI you can afford to download Naptime, Servicely or Greenify if you want (personally I use Nap & Serv) to enhance Doze or hibernation as in the case of Greenify (excluding as always the apps we want to be in the whitelist).
IMPORTANT: different words must be made for Custom ROMs, which being already optimized, and having a definitely more effective Doze than the basic stock, DO NOT NEED third-party apps like Naptime or Greenify. In this case, even setting everything as the guide, notifications will not arrive when the screen is off, except when you unlock the device.
so as far as custom ROMs are concerned, you just need to limit the apps as in the guide, leave in the background those you don't want to be touched, and always remove the optimization for these "important" apps, I always repeat "whatsapp gmail etc". In this way you will be able to activate energy saving quietly, the apps you prefer will not be touched, and you already have a Doze optimized like the rest of the system. The only thing that applies to Custom ROMs, is always to set the Governors as described above.
That's all at last :fingers-crossed:.
Attached here are my screenshots, with 8 hours of SOT, DIVIDED IN THREE DAYS, so sometimes the phone was idle as during the night or at work. With these configurations, in a single day, or in a day and a half, you will easily arrive even at 10 hours of SOT and maybe even beyond. I hope you fell asleep while reading, but I wanted to make a guide (even if long), to explain to those who may not be very practical, some things that can always be useful. A simple "thanks" is always welcome!
Greetings .:good:
Two more things: for more battery saving, u can disable automatic sync in settings menu (so sync when u want), and probably after some rebooting, it is possible that the governors will reset itself to the default one. So I suggest you check it out.
Really thanks for your concern about battery life stuff, and yup indeed on custom ROMs sometimes we can get up to 10hrs SoT without any mod or even a custom kernel (my experience)!
I'm looking forward to see how long the battery will last when we get Android Q update from MI..
AbboodSY said:
Really thanks for your concern about battery life stuff, and yup indeed on custom ROMs sometimes we can get up to 10hrs SoT without any mod or even a custom kernel (my experience)!
I'm looking forward to see how long the battery will last when we get Android Q update from MI..
Click to expand...
Click to collapse
Thank you very much! If I am not mistaken, beyond the various new functions, the "Extreme battery savings" will return. With an adequate optimization, as above (also to be as clear as possible with any type of user), we hope to see many beautiful new performances :fingers-crossed::fingers-crossed:
LionHeart90 said:
If I am not mistaken, beyond the various new functions, the "Extreme battery savings" will return. With an adequate optimization, as above (also to be as clear as possible with any type of user), we hope to see many beautiful new performances :fingers-crossed::fingers-crossed:
Click to expand...
Click to collapse
I hope that MIUI 11 will bring some new battery saving techniques as well!
Thanks for the guide, with it you cleared some doubts that I had, I just have a question, for battery/performace Anxiety can be better than Zen? For what I read the past days is an optimized version of Maple wich gives good balance between battery and performance.
:good:
Eddywarez said:
Thanks for the guide, with it you cleared some doubts that I had, I just have a question, for battery/performace Anxiety can be better than Zen? For what I read the past days is an optimized version of Maple wich gives good balance between battery and performance.
:good:
Click to expand...
Click to collapse
Thanks bro; Zen and Anxiety are so similar as they are also different. Each I/O scheduler we choose can be the most indicated according to what we do with our device. Let me clarify: Anxiety is better in term of battery saving comparing with Maple, "It prioritizes reads over writes but tends to starve writes more".
Zen is based on noop and deadline, very stable and have a great balance, for this reason i choose it. But as mentioned there are no schedulers better than others. But better according to our needs. My advice is to try them both, and see how you are in your daily use of the device :fingers-crossed::fingers-crossed:
LionHeart90 said:
Thanks bro; Zen and Anxiety are so similar as they are also different. Each I/O scheduler we choose can be the most indicated according to what we do with our device. Let me clarify: Anxiety is better in term of battery saving comparing with Maple, "It prioritizes reads over writes but tends to starve writes more".
Zen is based on noop and deadline, very stable and have a great balance, for this reason i choose it. But as mentioned there are no schedulers better than others. But better according to our needs. My advice is to try them both, and see how you are in your daily use of the device :fingers-crossed::fingers-crossed:
Click to expand...
Click to collapse
Thanks for your answer and your work.
:good:
Battery life is not the only thing I look for. Stock rom batter life is good enough after debloat in many crapps using saki. Stability, functionalities, security.. overall stock rom is the way to go for me at the moment. Did you mention restricting permission on apps?
Welp, after playing Free Fire for 1:20:00 and PUBG for 4:00:00, a little Browsing, my battery usage was of 76%, I don't use LKT because last time I try it my wifi started working weird, only use Snaptime. Evira 2.2.
:good:
I would like to know what do you think about zzmove governor that was added in Evira 2.3. Thanks.
I tried to use your settings but at reboot all configuration change to interactive or schedutil for CPU, msm-adreno-tz for GPU e anxiety for Scheduler I/O. I guess there are some conflicts with LTK.... I don't kwow how you have 8 hours of screen on your device...
Eddywarez said:
Welp, after playing Free Fire for 1:20:00 and PUBG for 4:00:00, a little Browsing, my battery usage was of 76%, I don't use LKT because last time I try it my wifi started working weird, only use Snaptime. Evira 2.2.
:good:
I would like to know what do you think about zzmove governor that was added in Evira 2.3. Thanks.
Click to expand...
Click to collapse
Sure bro, i just flashed it few minutes ago. After a complete recharge cycle, ill tell u my opinion :highfive:
empedocle86 said:
I tried to use your settings but at reboot all configuration change to interactive or schedutil for CPU, msm-adreno-tz for GPU e anxiety for Scheduler I/O. I guess there are some conflicts with LTK.... I don't kwow how you have 8 hours of screen on your device...
Click to expand...
Click to collapse
Mate, if u read with more attention, i wrote about it in my second post..
Just reconfig Governor already. It could be happen, is normal
Im going to test darknesssched with zen without sysconfig patcher (Had mobile data connection issues), alucardsched give me a little lag in PUBG, when I use darknesssched that dont happen, zzmoove dont convince me, it is based in conservative and hasnt been updated since 2015, for what I know cpu governors schedutil based are more "smart".
:good:
Nice guide, bro :fingers-crossed:
@LionHeart90 thanks for your useful guide!
just a curiosity, you dont use miui? from your screenshot you have a aosp rom?
iaio72 said:
@LionHeart90 thanks for your useful guide!
just a curiosity, you dont use miui? from your screenshot you have a aosp rom?
Click to expand...
Click to collapse
Yes man, i use the MIUI 10.3.3.0 If u see, the 2 screenshots about battery life have been taken from it :cyclops:
MIUI 10.3.3.0 instead of latest 10.3.5.0?
iaio72 said:
MIUI 10.3.3.0 instead of latest 10.3.5.0?
Click to expand...
Click to collapse
Yep
Hm, i am locked...and have no kernels installed. And I'm not planing to do it.
Did restrictions and debloat and this is what I get.
Since I am on 10.3.5. my battery is weaker..
On 10.2.7 I had 2 sims with lousy signal, and I was having about 7,8 h of sot and same use.
Now before this tweaks I was hardly getting 5h in 24h
Yesterday I had weaker use then ussual but still, this isn't very good..but I think it is better.
I dont like this 10.3.5.
Spoiler
Sent from my Redmi Note 7 using Tapatalk