Be careful about the phrase “True Random Number Generator”. There's a bit of hype in that phrase. You do not need to use a TRNG directly to do things like generate cryptographic keys — in fact, you should not, because all TRNG have biases, because even if the underlying physical process has a truly uniform probability distribution, it's impossible to build a perfect measurement apparatus. A good random number generator for cryptography is always hybrid: a cryptographically secure pseudo-random number generator ((CS)PRNG, also called a deterministic random bit generator ((CS)DRBG)), which is seeded by one or more entropy sources. A physical device whose purpose is to serve as an entropy source is sometimes called a “TRNG”, but a less misleading name is HRNG (hardware random number generator).
An entropy source needs to have two properties:
- It needs to be unpredictable. It needs to depend on a physical process whose outcome cannot be predicted in advance. This is typically a either a chaotic physical process or a process with physically theorized unpredictability such as radioactive decay.
- It needs to remain unpredictable even after the fact, i.e. its output needs to remain secret. An entropy source is no good if it's public. If your adversary can construct the same system state as you because they can read the same entropy sources, then they can generate the same keys that you're generating.
Obtaining entropy from outside is dodgy because it violates the second property. You have no way to know that the data you're collecting from smartphones is actually coming from a HRNG, and even if it is, you have no way to know that it's only sent to you and not leaked to anyone else.
Fortunately, if you do things right, then when you mix entropy sources, a bad source (not sufficiently random or not sufficiently secret) doesn't hurt: it'll contribute 0 to the total entropy of your system, but it won't nullify other, good entropy sources. So assuming that your server-side code is perfect and that at least one of your entropy sources is good, then the result is ok. The flaw in this argument is that code is never perfect.
All modern server hardware has a built-in HRNG. (If you don't trust it, you have no reason to trust the rest of the processor. So “I fear a backdoor in the processor's RNG” is not a valid argument.) Collecting additional entropy from outside has no benefit. It's a lot of infrastructure, meaning a lot of failure points and a large attack surface, for no benefit.
Gathering entropy in a distributed way like this does have a benefit for a very specific application: when you want to generate a public value which should be demonstrably random. In that case, allowing everyone to contribute their entropy, and using a public, deterministic way to combine all the submissions, does result in a demonstrably random value.