Thread: [Android][APK] Lack of Entropy Resolver / Lag Fix

This application will alleviate lag problems that may be seen while running the Android OS due to the random number generator working from a smaller than expected pool. Random data is used for all kinds of things including: UUID generation, session keys, SSL, etc. When the device runs out of entropy, the process blocks. That manifests itself as lag. The process cannot continue until the kernel generates more high quality random data which sometimes takes a little bit of time and then is shown to the user as 'random' lag.


Note that this APK is actually compatible with all Android versions, and all (armel) devices.

It seems that the lead developer from CM has also taken a look at this and indicates that the problem that was trying to be addressed might indeed not be assisted by use of this, but other problems that were unintended may be assisted by this. So in regard to what the application was originally made for, it seems as if it makes no difference, but on the kernel level it has some sort of impact. I think in a few more days we will learn some more about exactly what is going on here. Quote from Steve Kondik:

This is all fascinating, and I'm not totally dismissing that something is happening here.


Qualcomm devices have a hardware random device, which when coupled with the qrngd daemon feeds the kernel entropy pool. In normal operation of Android, I *never* see this pool actually get low unless running the qrngtest tool, in which case qrngd just fills it right back up.


Looking in drivers/char/random.c though, the functions which are called in the interrupt, input, and block device paths have an inner function add_timer_randomness which calls preempt_disable().


As a totally non scientific test, I turned all of these functions into no-ops and recompiled. This way, we're ONLY relying on the hardware RNG.


There's no change in entropy available because random numbers really just aren't being used all that often.


But now, I'm seeing a modest increase in interactivity on the device. Certain things feel smoother, and there is less UI jank. There's no change in frequency scaling or power usage as proposed earlier. qrngtest passes just fine as well.


What's going on here? I'm not entirely sure. We're either all crazy, or this is tickling a subtle scheduling bug in the kernel. More investigation is needed.

I'm thinking this may be a case of a fix being rolled out, but the fix is actually fixing something unintended and fails to fix the original problem.