Which capture formats and transport paths must the application accept?
Record camera model, interface, pixel format, resolution, frame rate and the simultaneous streams required. Check enumeration, capture and reconnect with the target firmware.
Integration lab / Video conferencing
Design the meeting experience.
Verify the complete system.
An Android board is one part of a conference terminal. Camera transport, audio routing, display output, network behavior and firmware recovery must be checked together with the intended application.
Build a project briefDownload acceptance sheet01 / Map the integration
Six questions before choosing a board
How will microphone input and speaker output be routed?
Identify USB or onboard audio paths. Test input/output device selection, mute, gain, restart and reconnect. Evaluate echo behavior with the actual application and room setup.
What must each output show?
Define output count, mode, orientation and touch mapping. Test hot plug, restart and simultaneous camera/display use. Connector presence alone does not establish application compatibility.
What happens when the connection changes?
Define wired or wireless transport, deployment restrictions and proxy requirements. Exercise call reconnect and recovery under a documented test network.
Who owns updates, recovery and application provisioning?
Request a build identifier, release notes and a recovery procedure. Agree who signs, distributes and validates each update, and how the approved configuration is restored.
What evidence makes a sample ready for a pilot?
Set pass criteria before testing. Save observed results and logs against a fixed hardware/software configuration; leave untested items explicitly open.
02 / Agree the handoff
Turn compatibility claims into acceptance records
The entries below are suggested checks. They are not measured results or a certification statement for any listed product.
| Area | Define before testing | Keep as evidence |
|---|---|---|
| Camera + audio | Peripheral models, formats, concurrent streams, routing | Device enumeration, application logs, observed reconnect behavior |
| Display + touch | Output modes, count, orientation, touch mapping | Mode report, connection diagram, test observations |
| Network | Transport, network restrictions, failure/recovery scenarios | Environment description and timestamped reconnect observations |
| Firmware | PCB revision, build identifier, application version, recovery steps | Release notes, update record and recovery test record |
| Pilot handoff | Pass criteria, exceptions, owner and retest trigger | Signed project acceptance record and unresolved issue list |
Project workspace / Candidate references
Compare the evidence you still need
Add up to four board references from product pages, then record your questions below. A saved candidate is not a recommendation or a verified configuration. Your candidates and notes stay in this browser tab’s session and are included when you generate a project brief.
No candidates saved yet. Open a product reference and choose “Add to project shortlist”.
03 / Prepare a useful enquiry
A project brief your engineering team can reuse
Fill in what you know. Blank fields remain “to confirm”. This tool assembles your entries locally in the browser; it does not send an enquiry. Generated briefs are kept in this tab’s session so you can review them on the contact page.
Review before sharing
A generated brief is a requirements document. It does not prove product compatibility, certification or availability.
Discuss the configuration with the team →04 / Define the evidence boundary
What should an AI-assisted review check?
Use the project brief with an AI assistant to identify missing requirements. Ask it to separate statements supported by the cited page from assumptions, and to leave unresolved compatibility questions open. Check every suggested product claim against current documentation.
Before a pilot decision
Reference desk / Android platform documentation
Separate platform support from board-level evidence
These official references explain Android platform behavior. They do not establish that a particular board, firmware build, camera, microphone or application has been tested together. Check the documented Android version and request configuration-specific evidence.
External USB cameras
Android documents an external camera provider and camera API path. Ask how the proposed firmware exposes your camera and which capture modes were tested.
Read the AOSP camera reference →USB digital audio
USB audio behavior involves platform implementation and audio policy. Record the intended input and output paths, then test routing with your application.
Read the AOSP audio reference →USB host APIs
Android’s USB host guide covers device enumeration and application access. A USB connector alone does not confirm the required host/API implementation.
Read the Android Developers guide →References checked 4 November 2026. The acceptance checks on this site are planning suggestions, not completed test results.
Common integration questions
Does a processor name prove camera compatibility?
No. Compatibility depends on the complete board implementation, firmware, transport path, peripheral format and application. Request evidence for the exact configuration you intend to deploy.
Can a board certificate be treated as approval for the finished terminal?
Do not assume that it can. Check the certificate scope, named model, configuration and applicable requirements with a qualified reviewer before relying on it for a finished product.
What should be saved when a sample passes?
Keep the tested configuration, procedure, pass criteria, observed results, evidence and exceptions. Retest when a relevant hardware, firmware, peripheral or application version changes.