public final class CallId

A fresh random (version 4) identifier in canonical form.

From SecureRandom, deliberately, and NOT from java.util.Random. The device runtime’s Random is this(System.currentTimeMillis()) over a 48-bit LCG – see vm/JavaAPI/src/java/util/Random.java – so two processes that reach this class in the same millisecond produce the same sequence of identifiers, and it is the SEED that collides rather than the 122 random bits, which is a far smaller space than the format suggests. A call id is not decoration: it is the key CallKit and Telecom hold the session under and the token the app’s server routes signalling by, so two calls sharing one aliases them – CallKit answers a duplicate report with CallUUIDAlreadyExists, and a server hands the wrong session an answer or an end.

Every port that supports calling implements secureRandomBytes, so this does not narrow which PLATFORMS the API works on – but it does require the runtime to be up, because the bytes come through the implementation. That is true wherever application code runs and is NOT true in a platform service the OS starts on its own: Android’s CN1ConnectionService can be created by Telecom in a process with no Display, and it mints its own id there rather than calling this. A port adding a similar entry point has to do the same.

Upper-cases a well-formed identifier, or returns null if it is not well-formed.

Ports call this on the way in, so a lowercase identifier from a server payload is accepted and stored canonically rather than becoming a call nothing can later find. A null return is the signal to answer CallError.INVALID_ID; this never throws, because the value routinely comes from off the device.