Function register_component 

pub fn register_component<C: NativeComponent>(kind: &'static str) -> bool

Register C under kind, so a slot whose params name that kind is served by this component — the module doc’s decision 2.

Call it once, from app or plugin init, on the platform main thread. Returns whether the registration was accepted: first-wins, so a kind already taken — including the built-in control kinds this build’s backend registers itself — is refused with a warning rather than replaced.

A wrong-thread call is refused, not silently accepted

The runtime is a thread_local!, and only the platform main thread’s copy is ever dispatched through: a registration made anywhere else lands in a runtime nothing will ever consult, and the symptom arrives much later, as a component that simply never appears. So this asks the platform first — Looper.myLooper() == Looper.getMainLooper() on Android (through the plugin substrate’s scoped attach), MainThreadMarker on iOS — and a definitive no is refused outright: nothing is registered, false comes back, and the reason is logged at error level.

A platform that cannot answer proceeds as before. On Android that means before the shell installs the plugin handles (NotInitialized) or if the probe itself fails; on a desktop/CI host there is no platform main thread to be wrong about at all, and nothing dispatches there in any case. Guessing “wrong thread” from an unknown answer would turn a legitimate registration into a silent no-show, which is the exact failure this is meant to prevent.

Registration is explicit on purpose: inventory-style link-time discovery is banned in this crate, because a stripped, LTO’d device build is exactly where it fails silently.