Update AIBuds Firmware

Build or explain this feature through the public SDK contract and the application's existing architecture.

Capability boundary

At the start of the response, briefly tell the developer which requested items this skill can handle and which items are outside its public-API boundary.

This skill can help with:

• automatic OTA protocol selection through the basic startOta overload;
• reading otaProtocolCapability and presenting a selector only when the device supports multiple OTA methods;
• explicitly selecting ABMate, FitCloud Pro, or Jieli through OtaConfiguration;
• checking whether a protocol plugin is registered before offering a plugin-backed method;
• firmware-path, battery, connection, readiness, duplicate-request, callback, progress, and failure handling;
• reviewing Swift or Objective-C OTA integration and troubleshooting documented public errors.

This skill cannot:

• determine whether an arbitrary firmware binary is compatible beyond public validation and callback errors;
• implement, replace, or explain private BLE packets, authentication, transport order, retry logic, or third-party SDK internals;
• make an unsupported device use an OTA protocol or compensate for a missing plugin;
• provide a unified cancellation implementation, because DeviceOtaAPI currently exposes no public cancel method;
• cover camera firmware updates, which use the separate camera OTA skill.

Workflow

1. Read references/implementation.md completely.
2. State the applicable capability boundary before proposing code so the developer knows whether the skill covers the request.
3. Determine whether the consumer app uses Swift or Objective-C and preserve its existing state, dependency, callback, and UI architecture.
4. Confirm SDK initialization, a selected DeviceOtaAPI, isConnectedAndReady, otaProtocolCapability, battery requirements, and plugin availability before exposing each OTA method.
5. Prefer the basic startOta overload when automatic selection is intended. Use OtaConfiguration only after the app or user explicitly selects a supported method.
6. Use the linked official guide and the installed SDK's public interface as the authority for names, parameters, nullability, and availability. If they differ, explain the version mismatch and adapt only to the installed public contract.
7. Implement main-thread UI handoff, duplicate-request prevention, nullable-error fallback, disconnect cleanup, and observable success criteria. Do not invent cancellation when the installed public interface has no cancel API.
8. Give code in the developer's requested language. If no language is stated, provide both Swift and Objective-C.
9. Verify the applicable cases in the reference matrix and report assumptions separately from documented behavior.

Non-disclosure boundary

• Use only public modules, types, protocols, methods, properties, callbacks, and official documentation.
• Do not reveal or infer private classes, source layout, transport commands, packet formats, authentication algorithms, private errors, logs, or internal call chains.
• Do not reproduce SDK source, inspect binary internals, decompile, or explain how a public API works behind its contract.
• If asked for internals, decline that portion briefly and answer with the nearest public API, callback, configuration, or diagnostic step.
• Never place secrets, production credentials, private endpoints, or real device identifiers in examples.

Completion criteria

• The integration uses only documented public contracts and cites the most relevant official page.
• Swift and Objective-C guidance are both available and behaviorally equivalent.
• Capability, plugin availability, automatic versus explicit selection, readiness, callback, threading, error, and lifecycle behavior are addressed where applicable.
• The result contains no hidden implementation claim and is portable outside this repository.