A Google Find Hub accessory is not completed by adding one advertising payload to generic BLE hardware. Google’s partner guide starts with the accessory specification, device proposal, commercial agreements, and approval path before firmware integration, self-test, third-party testing, and shipping approval. The hardware plan should accommodate those requirements from day one.
1. Confirm the target product and market
Define launch countries, Android users, product form, channels, and timing. A tracker card, key-ring tag, e-paper badge, and embedded module impose different battery, acoustic, button, antenna, and reset constraints. Google’s process also distinguishes location tags and non-audio devices when submitting a proposal.
2. Select a chipset and firmware route that supports the specification
Google states that it does not provide a general SDK or API for this integration; partners should confirm firmware availability with their SoC vendor or system integrator. Evaluate BLE features, memory, cryptographic processing, low-power states, production tools, and the update path together.
3. Make buttons, ringing, and factory reset dependable
The accessory specification covers ringing, state, identity, and factory reset. Hardware needs repeatable button actions and an acoustic path, while firmware handles authentication, timeouts, and abnormal states. Thin cards have less room for button travel and acoustic volume than conventional tags, so early samples matter.
4. Treat unwanted-tracking prevention as a core requirement
Find Hub accessories must support the applicable cross-platform unwanted-tracking requirements, including non-owner identification, accessory information, a temporary method to stop advertising, and public disablement instructions. The mechanical interaction, documentation, packaging, and support URL need to be planned together.
5. Test RF, power, and the complete state machine
Beyond normal BLE RF and regulatory work, validate pairing, ringing, identifier rotation, reset, recovery from power loss, low-battery behavior, and firmware updates. Battery life should be modeled from all operating states and measured on the production firmware in the representative product assembly.
6. Prove provisioning and traceability before volume production
Device identity, keys, model data, and manufacturing records must be provisioned securely and remain traceable. Registration rules for model or color variants can also affect project data. A pilot build should exercise provisioning, functional test, failure isolation, and rework permissions before shipment.
The customer owns product definition, industrial-design direction, brand, and channel. Yuli can support custom hardware, firmware adaptation, certification preparation, prototypes, pilot builds, and cold-pressed card manufacturing. Platform access, badge use, and shipping approval remain subject to formal review by Google or its approved partners.
