In theory devices are already supposed to collect entropy from device driver readings. Whether they do or not is an open question - it would require checking the kernel sources of lots of different shipping devices. It wouldn't surprise me to learn that some cheap devices have poorly done kernels that don't bother collecting entropy.
Rather than only using the accelerometers I think an easier and more robust approach would be to combine accelerometer data with a photo taken by the user (and then hashing the pixel data). A random photo of the users environment at the time they create the wallet should be plenty unpredictable. I filed this bug against the Android wallet some time ago:
https://code.google.com/p/bitcoin-wallet/issues/detail?id=219But it requires a lot of fairly boring programming to be completed first:
- The app has to be changed so it has a "welcome wizard" of some kind that helps the user set up their new wallet. Right now the app boots straight into the main screen and that expects the wallet to be initialised. I'd love to see a welcome screen but in the past Andreas wasn't keen for some reason.
- We need to switch bitcoinj to using deterministic wallets, and then migrate users who already have wallets over to the deterministic form. That in turn requires some fairly fiddly programming to ensure that memory usage isn't too large even when you've used the wallet for a long time, that it interacts properly with Bloom filters, that the core key management code scales properly and so on.
- Then we need to make it use deterministic ECDSA signatures as well, so we don't need any randomness to generate them. Otherwise you'd have to take a picture every time you sent a transaction! Or, of course, we'd have to store the seed and iterate it ourselves with a custom PRNG.
All those things are valuable by themselves, but as you can see, it's more work than you might have imagined.