Earbud software change control
Firmware can change pairing, controls, audio modes, microphone behavior, battery indicators and charging even when the housing does not change. A verbal message that the software is latest does not create a stable sample or a safe reorder reference.
Direct answer
Give every candidate build a unique version or checksum and release note. Install it on identified samples, then run pairing, reconnection, audio, calls, controls, noise modes, charging, indicators, reset, update and recovery across the intended phone matrix. Record known issues and approve the exact build in writing. Require notice and retesting before any production substitution or later firmware change.
Use this before requesting a quotation
Record product model, firmware version, build date, configuration and file checksum when available. Label the physical samples carrying it. A filename such as final or new version is not unique enough for production approval or later failure analysis.
Ask what was added, corrected, tuned, removed or left unresolved since the previous build. Identify affected functions and regression risks. If no release note exists, build a short comparison list with the supplier before deciding which tests to repeat.
Pair, forget, reconnect, switch between left-only, right-only and two-earbud use, then test distance and ordinary interruption recovery on intended phones. Record operating system and app versions. Test multipoint or companion-app functions only when included in the controlled product scope.
Run music, calls, microphones, play and pause, track changes, volume, voice assistant, wear detection, ANC, transparency and any game mode that the model actually supports. Note prompts, latency, unexpected resets and left-right inconsistency. Link specialist sheets for microphone, latency and battery observations.
Verify earbud and case indicators, app battery display, low-battery prompts, automatic power behavior and charging detection. A firmware build can alter reporting without changing the cell. Compare displayed states with the controlled charging-case and battery tests.
Follow the intended update path, including loss of app focus or connection only when the documented procedure permits it. Confirm factory reset, re-pairing and recovery from a failed update. Do not deliberately interrupt power if that is outside the approved method or could damage the sample.
List every open issue, its customer effect and the decision to accept, correct or block. Approve model, build, sample IDs and date in writing. State that firmware, configuration, prompts and companion-app changes require notice and a defined level of retesting before shipment or reorder.
Reusable buyer brief
Product model and physical sample IDs: Firmware version, build date and checksum: Previous approved version: Release-note changes and affected functions: Phone, OS and companion-app matrix: Pairing, reconnection and side-use result: Audio, call, control and mode result: Charging, battery display and prompts: OTA update and factory-reset result: Recovery path and result: Known issues, owner and disposition: Approved build, approver and date:
Fill only the details relevant to your request
Before you send the request
It should name the exact build and samples, list changes, show the phone and app matrix, record functional and regression results, document reset and recovery, and state all accepted or blocked issues.
No. A later build may fix one issue and introduce another. Production should use the approved build unless the change is reviewed, tested and accepted in writing.
Yes when customers use more than one device family or operating-system version. Compatibility observations belong to the exact tested matrix and should not be generalized beyond it.
No. Firmware approval controls software behavior. Incoming components, assembly, battery, acoustic performance, appearance and packaging still need their own approved references and inspection plan.
Keep the request specific
The approval record must name the exact software that was tested. If production receives a newer build, it is a change request, not an automatic improvement. Review the release note, assess risk and repeat affected and regression tests before acceptance.
Send this checklist on WhatsAppEditorial method
This checklist applies practical quality-management principles to earbud software: identifiable versions, documented changes, risk-based regression checks, written approval and traceable exceptions. It does not assume MINJI developed or owns the firmware for every catalog model.
Ready with the key details
Send the product reference, estimated quantity and destination so the conversation starts with useful context.
Continue on WhatsApp