To get randomness, you must obtain sufficient initial entropy from some "really random" events, that come from physical systems. Once you have sufficient initial entropy, you can extend it indefinitely with a cryptographically secure PRNG. The PRNG being a deterministic process, its output is not impacted by whatever other process may run at the same time on the machine.
The OS kernel is in ideal position to collect that initial seed, since it has direct access to the hardware. A good OS will collect hardware events to feed its internal pool, and run the PRNG, and provide an API to get the PRNG output. On iOS, this is the SecRandomCopyBytes()
function, that itself reads the /dev/random
special file (in iOS, like in OS X and FreeBSD, /dev/random
is identical to /dev/urandom
). By using it you are already doing fine; it already has all the cryptographic security that you can reasonably hope for; its security won't be impacted by running animations since the initial seed is gathered quite early in the booting process. On Android, use java.security.SecureRandom
-- same discussion (it uses Linux's /dev/urandom
).
In much older days, some people were talking about Java applets, that, by definition, were sandboxed and could not access the OS to obtain good randomness. These applets thus needed to find random events from other sources, and about the only one that remained was measuring the speed at which the OS scheduler could switch between two threads (e.g. see this code). That thread-spinning method required an otherwise mostly idle machine; otherwise, the produced numbers were severely non-random. Other methods leveraged the user: they asked the user to wiggle the mouse, and the applet would use the successive pointer positions as source of entropy.
Fortunately, these atrocious gimmicks are things of the past (or so we hope... because sometimes, some developers for banking systems get "creative"). For an app on a smartphone, you have access to the OS facilities, so use them and be happy.