Related
[Q] official Android 2.2: real changes & limitations? (vs. 2.1 & custom 2.2-ROM's)
Hi!,
I'm thinking about buying the Motorola Defy and putting Android 2.2 on it (I want/need 2.2). Now that the official 2.2-release is available, I'm wondering about the advantages and limitations of it in comparison to the custom builds available here.
I know about possible warranty limitations of rooting the device, the possibility to tweak it much more through rooted/custom-builds (e.g. extreme overclocking and total deletion of bloatware) but can someone help me with the following questions?
I'm not intrested in extreme overclocking, but I am intrested in aiming at high achievable performance under stable/safe and 'easy'/every-day conditions.
I'm quite computer literate (extensive software user for scientific research, some programming,...), but it would be my first smartphone, so the questions might seem dumb. Sorry! :
-What's the real performance gain of the official 2.2 (compared to 2.1 and/or custom ROM's)? (I find loads of benchmarks of OC'd 2.2-custom ROMs and of the official 2.1, but not of the official 2.2)
-Is it possible to overclock (for performance) and/or underclock (for battery) the official 2.2 to some extend (without rooting), e.g. from within 2.2 or Motorola's software or with an app?
-Is it easy to really shut down all the bloatware with the official 2.2? (Not necessarily deleting it, but at least not letting it run in the background and slowing down the device)
-Is it possible to use another keyboard (software/app), without rooting it?
These might seem questions not related to custom 2.2-builds and XDA, but I think any insights from people who know both 'worlds' might be very welcome. It might help me see (1) if I will by the Defy and (2), if so, if I would root it or just do the official 2.2-update.
As such, other insights on why I should or shouldn't go the official vs. rooted 2.2-way are always welcome!
thanks in advance!!!
bblubb said:
-What's the real performance gain of the official 2.2 (compared to 2.1 and/or custom ROM's)? (I find loads of benchmarks of OC'd 2.2-custom ROMs and of the official 2.1, but not of the official 2.2)
Click to expand...
Click to collapse
Dunno. The people who do the benchmarking are usually the same who mod their phones to the max.
-Is it possible to overclock (for performance) and/or underclock (for battery) the official 2.2 to some extend (without rooting), e.g. from within 2.2 or Motorola's software or with an app?
Click to expand...
Click to collapse
No. Apps that change the clock speed need root access.
-Is it easy to really shut down all the bloatware with the official 2.2? (Not necessarily deleting it, but at least not letting it run in the background and slowing down the device)
Click to expand...
Click to collapse
Freeze the bloatware with Titanium. You'll need to root your phone, but you can defrost frozen apps if you want them to run again.
-Is it possible to use another keyboard (software/app), without rooting it?
Click to expand...
Click to collapse
Yes.
I'm not intrested in extreme overclocking, but I am intrested in aiming at high achievable performance under stable/safe and 'easy'/every-day conditions.
I'm quite computer literate (extensive software user for scientific research, some programming,...), but it would be my first smartphone, so the questions might seem dumb. Sorry! :
The default settings of the Defy makes it a battery hog... Default settings are something like 30/300, 48/600, 58/800.. i use 20/300, 40/700, 58/1100... for the same amount of usage my phone last about 3 times longer... And this from someone whose 1st Android device is the Defy...
The principles of OCing a Mobile CPU is same as Ocing a Computer CPU...
-What's the real performance gain of the official 2.2 (compared to 2.1 and/or custom ROM's)? (I find loads of benchmarks of OC'd 2.2-custom ROMs and of the official 2.1, but not of the official 2.2)
A noticeable gain... Apps open up way faster as well since custom ROM's are devoid of any bloatware... And I am talking about real world performance not benchmarks (Though I'd like to say here that my Quadrant score is 1550+ on a Custom ROM and 1100+ on stock 2.2)
-Is it possible to overclock (for performance) and/or underclock (for battery) the official 2.2 to some extend (without rooting), e.g. from within 2.2 or Motorola's software or with an app?
No it is not, Overclocking apps require Root access...
-Is it easy to really shut down all the bloatware with the official 2.2? (Not necessarily deleting it, but at least not letting it run in the background and slowing down the device)
Titanium back up is the easiest way, any easier than we'd have had 200+ different ROMs and not 10....
-Is it possible to use another keyboard (software/app), without rooting it?
Yes, there are some available..
These might seem questions not related to custom 2.2-builds and XDA, but I think any insights from people who know both 'worlds' might be very welcome. It might help me see (1) if I will by the Defy and (2), if so, if I would root it or just do the official 2.2-update.
As such, other insights on why I should or shouldn't go the official vs. rooted 2.2-way are always welcome!
it is something like having a Core i7 2600K. You can let it be the way it is at 3.4 GHz and it'll still be fast... But add a custom cooler, water bloc maybe and the same chip will do 5 GHz... and still last you the same period of time... Choice is but yours how do you wan it to be...
thanks a lot for the input!!
I suspected that benchmarks would rather be made by uers that tweak and overclock their device, but I was hoping on the need for comparison-benchmark, helping me to chose whether to root or not
A quadrant-score of 1100 on the stock-2.2 doesn't seem bad. (I'm not to familiar with quadrant-benchmarks, as I don't own a smartphone yet (!) , but from memory, it seems quite higher than the benchmark scores I saw on stock 2.1.)
It's such a pitty that even underclocking (and/or limited overclocking) isn't possible without rooting . Does that mean that I also need to install another firmware, or can I 'root' (as 'unlock') the firmware to make (limited) under/overclocking possible with the original firmware?
What's the difference between using Titanium and using LauncherPro to cancel the unwanted lags due to bloatware? (I suspect that Titanium deletes the apps, while LauncherPro shuts them off/don't let them launch on start-up. Is this correct? Beside freeing up more space, does Titanium than also speeds up things more than LauncherPro?)
Sorry for the many questions!
ow! Strangely enough, checking the Quadrant-results for the Defy on the stock-Android 2.1 without overclocking, I found values around 1050-1150 ( on smartphonebenchmarks.com )
That would mean the official 2.2-update doesn't improve anything on the speed-level :s
Am I missing something? I read that Android 2.2 was faster than 2.1.
Android 2.2 is definitely faster. The differences are well documented.
Improved performance
Performance of the browser has been enhanced using the V8 engine, which enables faster loading of JavaScript-heavy pages.
Dalvik Performance Boost: 2x-5x performance speedup for CPU-heavy code over Android 2.1 with Dalvik JIT.
The graph to the right shows the performance speedup from Android 2.1 to Android 2.2 using various benchmark tests. For example, LinPack is now more than 5 times faster.
Kernel Memory Management Boost: Improved memory reclaim by up to 20x, which results in faster app switching and smoother performance on memory-constrained devices.
bblubb said:
What's the difference between using Titanium and using LauncherPro to cancel the unwanted lags due to bloatware? (I suspect that Titanium deletes the apps, while LauncherPro shuts them off/don't let them launch on start-up. Is this correct? Beside freeing up more space, does Titanium than also speeds up things more than LauncherPro?)
Sorry for the many questions!
Click to expand...
Click to collapse
Launchers like launcher pro are just a graphical interface for your home screens. They don't stop bloatware from starting up.
Titanium can delete them. Better yet, it can freeze them. This makes the system thinks they're gone, but you can easily unfreeze them. Installing official updates can break if the bloatware is gone, so freezing is safer.
Rooting the phone is a trivial task. I don't understand why are you even bothering about it. For most people is a single click and voila!, rooted phone!.
Furthermore, you can unroot, or flash a new ROM, and revert to the state the phone was when you bought it.
Right now it's more difficult to overclok than to root the phone or flash a ROM... and overclocking itself is easy enough...
Sorry. I thought rooting was a one-way-only ride, cancelling e.g. the warranty.
But I might have mistaken 'rooting' as such, with some specific custom-ROMs which cannot be rolled-back.
If rooting + freezing bloatware with Titanium is enough to make the official 2.2 be a lot more productive than the original 2.1, and still keeping it possible to run all official updates, I might just go that way.
Than only will I see if I would like to further over/underclock it and/or put a custom-ROM or not.
From what I read, the Defy is quite powerfull in itself, when cancelling the bloatware. Whith 2.2 on it, I might do it without overclocking. Maybe rather underclock it sometimes if that might help increase battery-life when it's not in intensive use.
I read quite some articles and posts comparing Android 2.1 with 2.2, convincing me 100% I wanted Android 2.2. I'm just confused about their (stock)-results on the Defy, but that might be due to the very-very low amount of tests/benchmarks of both stock-ROMs on the Defy.
Thanks a lot for all the info!!
https://android.googlesource.com/device/samsung/tuna/+/095e19a54d217474e14fcdf769a0369ef3f4d30c
Reverse engineer this ?
Don't know if this will work but as far as I know it's not required by Jelly Bean?
Is this a good Idea ?
I am currently testing it. See my CM10 thread for the latest nightly to try this. This should fix all overclocking issues hopefully
Source code:
http://review.cyanogenmod.com/#/c/23076/
very good
Very very very good work guy .....
Why do you want to remove the HAL? As soon as it was fixed we didn't have more problems setting the clocks during screen on/off, so I don't see a reason to remove it and in the end it should cause more problems that its worth.
Steve's comment makes me worried:
Why not just make the code a little smarter and detect this stuff automatically?
Soon we will be using boostpulse in many more places in the framework to improve interactivity in ways that can't be done from the kernel alone.
Click to expand...
Click to collapse
Using boostpulse in the framework is NOT smart at all. I think this stuff should be done in the kernel level only. Other devices have other types of code to boost the frequency when it receives a touch event (all kernel level) instead of merging it to the userspace framework.
Hi all,
I hope someone ran into this before, I have the issue that my CPU is running on its maximum frequency which burns up my battery very fast... I am currently running cm10.1 with the stock kernel and pegasusq governor. Reason why I'm back to the stock kernel is because I noticed the problem while trying the new devil kernel.
Thanks in advance!
Sent from my GT-N7100 using xda app-developers app
In devil kernel make sure you don't have performance governor.
Sent from my GT-N7100 using xda premium
An expected suspect: LBE/?
steijn0 said:
Hi all,
I hope someone ran into this before, I have the issue that my CPU is running on its maximum frequency which burns up my battery very fast... I am currently running cm10.1 with the stock kernel and pegasusq governor. Reason why I'm back to the stock kernel is because I noticed the problem while trying the new devil kernel.
Click to expand...
Click to collapse
If your issue is truly a kernal/governor problem, this suspected data conflict may not apply... but I recently noticed Note 2 CPU stuck at 1600MHz.
Searching, encountered posts mentioning lost images (which I have, also, recently encountered...?), a media scanner bug, and likelihood of flashing required to correct; however, 'noticed LBE Security Master consuming an unusually high amount of the battery...? 'Reverted LBE (Titanium Backup) to an earlier backup.
Installing earlier data (only) probably would have been sufficient, as my originally-installed version (4.4.2803) of LBE is still in use (updating would have required uninstalling and reconfiguring from scratch... and I've been satisfied with the control this version provides... considering reports of LBE bloat and recommended alternatives, I stuck with older version).
It worked: CPU clock speed is normal again. I'm guessing recent virus database update was incompatible with the older LBE version.
'Suppose LBE virus database updates should, going forward, be ignored (unless data conflict is confirmed and deemed worthy of correction... perhaps unlikely for older versions). Knowing, now, what to look for, I may try a future database update, immediately reverting if there's another CPU conflict.
Hey everyone, this is a shared page
Version 2.0.0 released!
This version introduces performance tuning, power management control, and an optional MMC I/O queue extension/timing change.
Tested on HTC One Insertcoin 7.0.6, Android 4.4, Sense 5.5
For those of you who have seen reboots / black screens that seem to be caused by Seeder, I suspect it may be due to the power management implemented in previous versions. Disabling power management (by unchecking "Suspend RNG service while screen off") may help. In my testing, battery impact was negligible (less than 2% per 24h).
The performance profiles are Light, Moderate, and Aggressive, and they control how frequently rngd wakes. The default configuration (Light) is unchanged from previous versions. Moderate and Aggressive may impact battery life (slightly), but may also help on devices where the entropy pool is drained quickly and often.
Last but not least, the "Extend I/O queue" option increases the nr_requests on MMC devices to 1024, and increases the dirty page expiry time, allowing more outstanding writes to accumulate. This may allow the I/O scheduler to make better decisions and combine more writes; some users have reported an improvement under heavy I/O.
Feedback appreciated!
---
On some (older) versions of Android, the JVM (and other components) often read random data from the blocking /dev/random device. On newer builds, this problem has been solved, yet depletion of the input entropy pool still seems to slow devices.
So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.
Result? Significant lag reduction (for some people)!
Note - if you want to try it, you must be running a rooted device, and you only need to install one of the APKs (latest version is best). Then, just open it, and turn it on. The other files (patches / .zips) are intended for recompiling, packaging, and init.d integration. If you uninstall the app, either turn off rngd first (open, and click the on/off button), or reboot afterwards; the UI does not presently kill the daemon on uninstallation.
For more information on using the .zip flashing method, see Ryuinferno's post here:
http://forum.xda-developers.com/show...postcount=1924
FAQ
Q: Do I need the .apk or the .zip?
A: The easiest method is simply installing the latest .apk, attached below. You do not need to use the patch or the .zip file.
Q: What is the patch for?
A: The patch file contains the source differences needed to recompile the Seeder version of the rngd binary. You only need it if you want to recompile rngd yourself.
Q: What is the .zip file for?
A: The .zip file contains the latest rngd binary. It is intended for ROM builders or those who want to build their own CWMR packages.
Q: Seeder keeps shutting down! Does this mean I have to restart it?
A: The Seeder UI is only used to configure and start/stop the RNG service, which runs in the background. The RNG service is not visible from Android, since it is a native Linux process. You can terminate the UI at any time, and the service will continue running.
Q: Does seeder cause excessive battery drain?
A: Seeder 1.2.7 introduced an RNG service power-saving mode. The process automatically suspends whenever the screen is off. The code is actually in the rngd native binary, so suspend/resume events happen independently of the UI; you can see it in action by attaching to the running process with strace. This means that battery drain while the screen is off is highly unlikely.
While the screen is on, the RNG service simply polls a file descriptor every second, and, when needed, injects a small amount of random data into /dev/random (and calls an ioctl). It's unlikely that this would present enough load to trigger a CPU governor state change at 10mhz (let alone 200mhz), so it shouldn't impact battery life. Having said that, I have received sporadic reports that it does reduce battery life on some devices. They may be coincidental (other software installed at the same time), or due to extra device use while testing. Or, they may be real. If you think your battery drain has increased, shoot me a PM!
Q: How can I see the RNG service Linux process?
A: In a terminal, type: ps | grep rngd
Q: How do I uninstall the .apk?
A: Launch Seeder, and stop the RNG service. Then, uninstall the app as you normally would. Alternatively, uninstall the app, and reboot.
Q: Is seeding /dev/random with /dev/urandom safe?
A: Seeding /dev/random with PRNG-derived data does reduce the quality of its random data. However, it's worth noting that nearly all major OSes except Linux do this. Linux is one of the very few to offer a blocking RNG device. And, at least as of ICS, Dalvik doesn't even read /dev/random, so there is little difference anyway.
Updates
There has been a lot of controversy about Seeder/rngd. In newer versions of Dalvik, nothing touches /dev/random, and yet many users (including myself) still notice a lag reduction. There are theories ranging from kernel lock contention to UI polling load when crediting the entropy pool to simply kicking the governor. And many who believe it's all placebo. I'm trying my best to figure out what exactly is happening, and others are as well.
Someone asked how I arrived at the conclusion I did when I started the thread back in November, and I posted this; I think it might be better served here:
A while back one of the webapps I was hosting on Tomcat (server-side) was experiencing some inexplicable latency and while stracing java I saw it frequently hanging on read()'s from /dev/random. I checked the available entropy, and it was constantly under 250 or so. It was a VM, no HWRNG, so I decided to use rngd to push urandom->random.
Dropped session creation times under load from 5-10 seconds to less than a second.
It's worth noting that Linux is one of very few OSes that have a blocking RNG device. Free/OpenBSD, Windows, etc.. essentially only provide urandom. It's generally considered secure, even for long-term crypto keys, so long as the initial seed is big (and random) enough.
Checked on my device, and saw a few processes grabbing /dev/random. /proc/sys/kernel/random/entropy_avail reporting depleted input pool. Figured it was worth a shot, so I rebuilt rngd for arm (with a few patches, linked on first page), and tried it out. It made a significant difference. Posted it up on this thread, and had a lot of positive feedback. Wanted to get into Android development, so figured.. why not wrap a little UI around it. More positive feedback, so I threw it on the market as well.
I had no idea it would take off like this and was shocked when I saw it Thursday morning. I'm in the awkward position now of explaining why it seems to work for some people, and not for others, especially given the fact Dalvik doesn't have references to /dev/random as of ICS. Theories abound, but it looks like it might be an issue of polling the UI for input events when the entropy pool drops (which never happens so long as rngd is running).
I'm doing this as a hobby. I'm a *nix admin by trade, and can only spend time working on this stuff on evenings and weekends, and the last few weeks have been kinda nuts.
I want to stress to everyone that:
a) It doesn't work the way I thought it did on later Android builds, but it does reduce latency for me and many others even on these builds,
b) I'm offering (and always will offer) Seeder for free to everyone on XDA,
c) Like I say in the market description, if anyone has purchased it and it isn't working, PLEASE email me for a refund (and let me know what device you're on if you're willing).
I was one of the first to root the Captivate glide (my first Android phone), and submitted the A2DP bitpool patch; I was active in the n900 community. I hope everyone understands that I'm doing my best here!
I hope the technique proves useful to people, and if there is in fact contention at the kernel level, I hope it's solved so we all benefit.
Version 2.0.0 attached. No changes.
Version 2.0.0b1 attached. New performance profile selector, I/O queue extender, and power saving control. Improved root checking.
Version 1.4.0 attached. Major refactoring. Service control now fully asynchronous.
Version 1.3.1 attached. No changes from 1.3.1-beta.
Version 1.3.1-beta released. New root check method during ANR-sensitive code.
Version 1.3.0 attached. Proper IntentServices for process control, and notification on upgrade / loss of root / autostart failure.
Version 1.2.9 attached. Yet another update to the upgrade/autostart code.
Version 1.2.8 attached. Asynchronous startup of rngd during boot; this should solve the remaining autostart problems some users have reported.
Version 1.2.7 released. This version introduces a much more efficient suspend-on-sleep mode for rngd.
Version 1.2.6 released. This version reverts the suspend-on-sleep rngd change which may have been contributing to new latency. I'm sorting out a better way of implementing it.
Version 1.2.5 released. This version should fix the autostart failure some users have seen.
Version 1.2.4 released. This version implements a progress bar displaying your currently available entropy, as well as automatic rngd restart on upgrade.
Version 1.2 released. This version implements rngd suspend-on-sleep, and contains minor user interface updates, more robust process and superuser checks, and a new icon (thanks Nathanel!)
Version 1.1 released. This version uses the release signature, so you will need to uninstall the old XDA version first!
This version fixes the issue some users were seeing on later Jellybean ROMs, where the UI would misreport the RNG service status.
Caveats
There is a (theoretical) security risk, in that seeding /dev/random with /dev/urandom decreases the quality of the random data. In practice, the odds of this being cryptographically exploited are far lower than the odds of someone attacking the OS itself (a much simpler challenge). It's worth noting that as of ICS, Dalvik uses /dev/urandom exclusively, anyway, and that Linux is one of very few modern operating systems that even offer a blocking RNG device to begin with.
Support for rngd suspend-on-sleep was added to Seeder 1.2. It should no longer impact battery life while the device is asleep.
There has been a large amount of speculation on why/if this actually improves performance on ICS+ devices. I'm continuing to investigate and will post updates to this thread.
If you try it, let me know how it goes.
ROM builders - feel free to integrate this into your ROMs (either the .apk / application, or just the rngd binary called from init.d)!
If anyone's interested, I've launched a paid app on the Play store for non-xda users. As I add features I'll post the new versions here as a thanks to you guys (and xda community at large for being such a great resource). But if anyone's interested in the market's auto-update feature, just thought I'd mention it.
Cheers!
Thread original => http://forum.xda-developers.com/showthread.php?t=1987032
Trying it right away
Sent from my HTC One using Tapatalk
Noticed some changes, thanks for this :3
Sent from my HTC One using Tapatalk
How about posting from the very top that this is a shared page, not your work/typing and not copy/paste as if you did it yourself...
Other members clearly indicate a share or not.
Dude, why not just link this to lambgx02 The developers Page and tell everyone that it works for you. Did he give you permission to post his work since it is a paid app on Google Play? Not copy and paste his work. https://play.google.com/store/search?q=seeder 2.0&hl=en
Version 2.0 came out a year ago. There has been no updates since
Thread Closed - Original project HERE.
I'm on the sm-f926u1 that can't be rooted but I do have shizuku for some permissions but just curious if there's anyway to make any kind of tweaks to the kernel to squeeze some more performance out this device?
You need system file root access for kernel tweaks/changes. In other words your phone would have to be rooted.
*edit*
Outside of that one performance setting that exists is "enhanced processing" under battery in device care. Drawback would be increased charging intervals, but when I used it I could get about 12 hours with fairly active use.
But if by performance your looking for i/o scheduler, governor and etc you will need the phone rooted.
spart0n said:
I'm on the sm-f926u1 that can't be rooted but I do have shizuku for some permissions but just curious if there's anyway to make any kind of tweaks to the kernel to squeeze some more performance out this device?
Click to expand...
Click to collapse
more performance? the performance is already high
Someone on YT water cooled their phone, got some great perf that way, but do you really want to carry all that stuff around with you?