Develop Bugs

Speedup your Hero (please read)

Guys,
Browsing the web I stumbled up on to this article:
It describes how you are able to get a good performance out of your Hero, Hence that it's just a experiment so not sure if it will work!
http://www.majicware.com/HTC-Hero-Speed-Issues-Experimenting?vzWMwp
I'm going to post updates as I will test it.

The article actually sounds quite interesting...I've also noticed that killing tasks doesnt necessarily get rid of some of the lag (although I dont have that much lag to begin with).
I think I'll give this a try for a couple of days too.

Well lets keep us posted on this case. I will give a update tomorrow.

I'll see if that works for me =)
sounds promising =D
thanks for sharing

ill give it a try!

If the phone is syncing then it is definitely very laggy. This is also the case when the memory us low. Obviously if u have apps like task panel or the,music player running at the same time things will slow down too.
For me task panel has worked well. If I keep the free memory at around 50megs then there is almost no lag. I'll keep an eye out for other things as well

If the phone is syncing then it is definitely very laggy. This is also the case when the memory us low. Obviously if u have apps like task panel or the,music player running at the same time things will slow down too.
For me task panel has worked well. If I keep the free memory at around 50megs then there is almost no lag. I'll keep an eye out for other things as well

I have been using the Hero for a few days. On day one I hated it, it was so slow. Then I started using Taskiller to kill tasks like weather, clock, mail, peep etc that are running in the background. Not much help. In fact, it seemed the more frequent that I killed these tasks, the slower my Hero ran.
After a few days of use, I realized the trick to speed up the Hero (or android in general) is DO NOT kill tasks unless you are running our of memory. By running out of memory, I mean really out of memory. My Hero is using 160MB memory right now, which may seems a lot, but it is running very smoothly. Killing some tasks reducing memory usage to, say 90MB, wont' really speed it up. Unlike Windows Mobile, as long as your memory usage is not 99% and have memory left for additional apps to open, just leave it. Remember the Hero has 288MB memory, 100 MB is already reserved for the OS to run, and android memory management will kill unnecessary tasks for you when you run out of memory anyway.
Now, the important part. Do not kill tasks manually too frequently. You have to understand when does the Hero slow down: when it is fetching data. If you use an HTC widget, do NOT kill the relevant app that the widget requires it run in the background. For example, if you used the HTC music widget, don't kill the music app running in the background. If you killed it, you would notice a very significant lag when you go from another page to the page with the music widget. This is because the music widget is trying to open the music app and access the music on your micro SD. Once it is done, the music app will just become idle until you start playing music and there is no more lag. But if you killed it, the widget had to open the app every time you reach that page after killing the app. This causes lag.
The same go for the twitter widget. If you killed Peep running in the background, you will notice a lag when you go the page with the twitter widget. This is because the twitter widget is starting up Peep again and has to connect to your twitter account to check for new stuff. But if you leave Peep running, it will do so only at the regular time interval that you set.
I am now running the HTC clock widget, music widget, bookmark widget, twitter widget and full of stuff on all of my 7 pages home screen. I have clock, weather, music, peep, mail and many other apps running in the background. My Hero run very smoothly.
I hope this helps.

Hmmm... Well, I think it is pretty obvious and common sense that the apps used for active widgets should surely not be killed. For the others, I find that I am better off killing them. Even if this should not be the case, and the effect only "psychological", I still fail to see what would be a benefit of not killing the applications.

Android market should define some criteria that applications must meet before they're made available. Applications should also be benchmarked and rated wrt connectivity requirements, CPU-load etc. This would be a deterrent against applications that load automatically even when there's no config (like peep when there's no twitter account), or puts such load on device that it runs out of juice in a few hours (power manager). If this is done on android market one could also hope that vendors also would put a bit more effort into optimising their own stuff.

've stopped obsessively killing Apps...running smoothly. Android Dev video posted on similar thread reassured me that the OS is meant to take care of all that anyhow

phel21 said:
Android market should define some criteria that applications must meet before they're made available. Applications should also be benchmarked and rated wrt connectivity requirements, CPU-load etc. This would be a deterrent against applications that load automatically even when there's no config (like peep when there's no twitter account), or puts such load on device that it runs out of juice in a few hours (power manager). If this is done on android market one could also hope that vendors also would put a bit more effort into optimising their own stuff.
Click to expand...
Click to collapse
Well, I dunno; that way madness lies, or at least iTunes Appstore madness, where new apps, and upgrades, take weeks to get approved, and are still equally buggy. And new apps often get refused, for no good reason.
I like the timeliness of the Android store; and I'm suffering with dodgy apps too - my Hero currently won't last overnight on standby - but it's still miles better than the iPhone nonsense

Well I stopped using the task manager to kill apps for a couple of days....but there is no real speedup and its just the same.
BUT it also means that its pointless to kill the tasks to begin with since it didn't make a difference either (like other people are now saying). If anything, the browser and apps like people/contacts load up faster beacause they are still somewhere in the background (I used to always constantly kill these apps).
The part about not suspending the phone straight away has made a slight difference. Before, when I turned the screen on I constantly had a lag especially sliding the screen left and right and going to the messages page. But if I let it go into standby by itself, when I wake up the phone, it barely stutters (and if it does, its only for like a split second on the first slide).
...if only there was a shortcut to just lock the screen....

I found uninstalling 'Power Manager' sped my phone up massively. I shall try this and see if he's onto anything.
...if only there was a shortcut to just lock the screen....
Click to expand...
Click to collapse
Aren't there apps for locking in the market?

don't know will this speed up things and to whom it may apply, but until today i never ran my Stocks app, seeing as i don't care about stocks so i opened it, opened settings and found out it was set to update every 1h with 4 preset stock somethings....so those not using it might also wanna check that the thing is switched to Manually, one less task that shows up for no reason :/

Tone-Fu said:
I found uninstalling 'Power Manager' sped my phone up massively. I shall try this and see if he's onto anything.
Aren't there apps for locking in the market?
Click to expand...
Click to collapse
I've only come across the likes of lock 2.0 but I thought that was an alternative lockscreen...

cdmackay said:
Well, I dunno; that way madness lies, or at least iTunes Appstore madness, where new apps, and upgrades, take weeks to get approved, and are still equally buggy. And new apps often get refused, for no good reason.
Click to expand...
Click to collapse
Apple's problem is politics. I wasn't hinting towards any such subjective valuation for Android. What I'd like is a clear set of technical requirements (example: an application that auto-starts during boot even without necessary configuration data should not be accepted), and a site back-end with numerous emulators that runs applications through their paces to obtain performance/power/network rating before they are made available for download. Extensive testing would require manual configuration, test and monitoring, but even some simple automated tests could sort out the worst offenders. Ratings should be displayed with application descriptions on the site, and would also work as a simple form of tech feedback to developers about things they may need to improve.

good points.
I've since discovered that any app that registers to receive async alarms will be started at boot, even though it doesn't necessarily need to be. not really a problem, but the cause of a lot of processes running at boot for no obvious reason.

Hi Guys,
I'm Adam Saunders, author of the original article.
Just a thanks to everyone that is also trying the experiment. So far I've had a lot more positive results from people than negative, so the hunch is somewhere on the right track.
I was going to try and find an exact reason as to why killing tasks repeatingly will slow the device down. It's been said its the way that Android kills apps but saves the state, so the process isn't actually running, and by killing that off, the orphaned state is possibly the problem. Sounds feasibly, but not read anything official to back up that claim.

Confirmed, it's been three days since I stopped killing the processes and any lagging (which was very slight for me in the first place) is gone. Thanks for the tip, Adam!

Overclocking XDAndroid Rhodium

So I noticed a number of references in one of the mega XDAndroid threads to overclocking Rhodium. Sounded pretty simple, just a string of text with the desired frequency in a particular file.
A couple of questions for those who toyed with that:
1) was it stable and what was its fastest stable speed?
2) did it run uncomfortably hot?
3) is it possible to alter it on the fly (so you can run it slow when you're reading, and crank it up for video), or do you have to choose a speed preboot and reset to change it?
4) If it can't at the moment, be altered on the fly, might it be possible for some program to do that in the future?
5) finally, why is it so easy on adroid? It seems like no2chem has hit a bit of a wall in making his winmo project hum, but the references here made it sound like a pretty basic task.
Part of the reason I'm asking is flash 10.1 is due for android in Q1. The last I read of CPU requirements had them over Rhodium's specs by a lot. Mobile hulu access would be fantastic, and I'm planning to start dual booting this summer, once classes are done. It'd be nice if my TP2 could eek out enough performance for that.
Thanks

You could try adding this to your Startup.txt acpuclock.oc_freq_khz=650000, thats the one i use and its prettty nice, i havent notice any heating up at all.

devilcuban said:
You could try adding this to your Startup.txt acpuclock.oc_freq_khz=650000, thats the one i use and its prettty nice, i havent notice any heating up at all.
Click to expand...
Click to collapse
It does not sleep to death for you when you do this devil? I had to take the OC out of my rebuilds, because once the phone sleeps, it will not wake up.

Yep same here. If I add that line, once it goes to sleep in Android, it doesn't want to wake up again...

Reefermattness said:
It does not sleep to death for you when you do this devil? I had to take the OC out of my rebuilds, because once the phone sleeps, it will not wake up.
Click to expand...
Click to collapse
On the Hero one it does , on you build even tho its not really need it i've been using it for a while and it doesn't do it .
So interisting thing, it does go to sleep of death, the reason it didnt do it before for me its because i've been using with htc_battery_smem.fake=1, but as son as i disable that it went to sleep and didn't get up.

devilcuban said:
On the Hero one it does , on you build even tho its not really need it i've been using it for a while and it doesn't do it .
So interisting thing, it does go to sleep of death, the reason it didnt do it before for me its because i've been using with htc_battery_smem.fake=1, but as son as i disable that it went to sleep and didn't get up.
Click to expand...
Click to collapse
I did test and confirm this. I think what happens is with smem.fake=1 the phone actually never goes to sleep.... at least the sleep light never turns on. I will have to ask phh if this is the case.

Tried putting the overclock line in Startup.txt but it did not seem to change anything, at least according to the CPU Benchmark app. The battery line did seem to work though, as it thought it was charging even while not plugged in.
Is there a specific order that these parameters need to be added in? I just added the overclock line at the end and the battery one after that.
Using the latest non-sense 2.1 builds.

I'd love to add Rhodium overclocking support to my RogueTools application.
I think there is still a constraint though with write access to /system. I am hopeful that shortly the Rhodium kernel and rootfs developers will deviate out of the current read only SQSH model and go the way of the Vogue, Kaiser and Polaris hosting the system and data in separate EXT2 partitions on the SD Card. NAND would be the next step.
If someone knows another way to overclock on the fly once the system is up (post boot). PM me. Like I said, I'd love to add support for the Rhodium.

so nothing on the OC for 2.1 yet?
bump

I'm about to test overclocking with the SetCPU app. Worked fine on my rooted G1. I'll report back with my findings.
Edit: Did not work with custom and/or multiple devices selected. Can't push any higher than the stock 528. Blah.

on screen keyboard
when i put both sleep fixes and the overclocking cpu command in my startup text i get the on screen keyboard like in rhobuntu. how do i disable this? its not even usable it just lingers there and its very annoying

O.S.K. byebye command is msmvkeyb_toggle=off

OverClocking M2CW & IME
Data corruption is inevitable without running extensive stress testing to find a safe speed. I have yet to find one for msm7k processors, but surely Qualcomm has one. Benchmarking is not the same as stress testing. Such stress testing apps need to be run for several hours & even days. They can't test all functionality accuracy. Stress testing in themselves can cause hardware damage & even catastrophic failure.
Data corruption is often the "silent killer" and goes undetected by you or system checks ... until you need it most. It may be a config file, a message file, a contact database, an executable, a registry hive, a system file. Any non ROM file is vulnerable. Backup OFTEN & NOT while OC, even though BUed corrupted data is still corrupted. Quote "stable speed" isn't such just because device doesn't randomly lock up or reboot.
Every CPU and memory chip has different limitations. Same phones built on same date may not OC the same.
Don't OC when when building new Android data.img file, downloading update files or apps, extracting or creating archived files, installing apps, encrypting or decrypting.
OC doesn't help Project XDAndroid developers. I suspect many "bugs" they spend valuable time on are OC related.
The msm7k processors supported by Project XDAndroid are a speed scaling processor designed for optimum performance vs. battery runtime, ramping up and down the processor speed based on demand. Average device use doesn't utilize full processor speed.
OC is most noticeable in OS boot times (when OC is initialized prior to), certain multitasking operations, some video playback, CPU intensive games, & to a lesser extent web browsing. Many factors determine the effectiveness of OC especially whether graphics are hardware or software supported.
Your OC device may actually perform worse, noticeably more sluggish, or more jerky than when not OC. Ever notice on some boots into Android it takes forever for your carrier to be detected & displayed on the lock screen and it may creep along as if your processor was hijacked by a random process? Ever notice when you open the app drawer not all your apps are displayed?
OC does use more energy thereby shortening battery run time and producing more heat. Don't complain about battery life if you are OC. Accurate battery charge state & battery run time are not synonymous.
While OC may shorten hardware lifespan it most likely, though possible, will not lead to a catastrophic failure in the typical device lifetime due to the rate of current technological innovations and average length of ownership.
My overall performance satisfaction with Project XDAndroid is best when not OC, especially now that hardware 3D is supported or partially supported as in my rhod500.
OC at your own risk.

Seeder entropy generator to provide significant lag reduction

Spotted this interesting thread over at Android Software and Hacking, which has gone viral today: http://forum.xda-developers.com/showthread.php?t=1987032
Partial quote:
Hey everyone,
So, I was experiencing significant lag as we all do from time to time, and decided I was going to get to the bottom of it.
After tracing and debugging for hours, I discovered the source of 90% of Android's lag. In a word, entropy (or lack thereof).
Google's JVM, like Sun's, reads from /dev/random. For all random data. Yes, the /dev/random that uses a very limited entropy pool.
Random data is used for all kinds of stuff.. UUID generation, session keys, SSL.. when we run out of entropy, the process blocks. That manifests itself as lag. The process cannot continue until the kernel generates more high quality random data.
So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.
Result? I have never used an Android device this fast. :good:
It is literally five times faster in many cases. Chrome, maps, and other heavy applications load in about 1/2 a second, and map tiles populate as fast as I can scroll. Task switching is instantaneous. You know how sometimes when you hit the home button, it takes 5-10 seconds for the home screen to repopulate? Yeah. Blocking on read of /dev/random. Problem solved. But don't take my word for it .. give it a shot!
Click to expand...
Click to collapse
You can just install the apk on a rooted device and simply enable/disable via the app.
Has anyone else with an HTC Desire found it to be of any added benefit? I'm not seeing much of performance boost myself but will keep observing either way.

It kills my battery on my sensation and my desire! And performance is just marginally better on big apps like maps and browser
Sent from my HTC Sensation using xda app-developers app

topgeardave said:
It kills my battery on my sensation and my desire! And performance is just marginally better on big apps like maps and browser
Sent from my HTC Sensation using xda app-developers app
Click to expand...
Click to collapse
Yes I agree. Though I didn't have any battery issues but the performance was only slightly better.
Sent from my HTC Desire using xda app-developers app

What is ART?..you may ask. (4.4 Art vs. Dalvik )

I DO NOT take any credit for the information provided. Just helpful information.
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!
Special thanks to Bart Tiemersma for his contributions!
Credits : http://www.androidpolice.com/2013/1...-in-secret-for-over-2-years-debuts-in-kitkat/
Sent from my LG-LS970 using XDA Premium 4 mobile app

[APP/APK] Seeder 2.0.0 entropy generator to provide significant lag reduction

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.