Silicore Logo Silicore

How to Choose an Android SBC Manufacturer for a Production Product

Evaluate an Android SBC manufacturer by BSP ownership, component control, factory testing, compliance support, lifecycle planning, and engineering response.

How to Choose an Android SBC Manufacturer for a Production Product

A board can pass a two-hour demo and still be a poor production choice. We have seen samples arrive with a clean Android launcher, working HDMI, and an attractive unit price, then fail the questions that matter six months later: nobody can reproduce the image, the Wi-Fi module is changed without notice, and the factory test only checks whether a power LED turns on.

Choosing an Android SBC manufacturer is therefore less about finding a board with the right CPU and more about finding a team that can keep hardware, Android, and production under control at the same time. Procurement should be able to verify supply and commercial terms. Hardware engineers need revision discipline and credible validation. The software team needs a maintainable BSP. If one of those parts belongs to an unnamed third party, put that dependency in the risk register before placing an order.

Start with the Product, Not the Supplier Catalog

Send every shortlisted supplier the same requirement pack. A useful pack states annual volume, production lifetime, display and touch parts, enclosure conditions, required interfaces, Android version, security policy, target markets, certifications, and who owns the application. Include the details that are likely to break the project: exact LCD timing, whether CAN must be isolated, cold-crank behavior, maximum boot time, and whether OTA rollback is mandatory.

A vague request for “an RK3568 Android board with 4 GB RAM” invites quotes that cannot be compared. One vendor may quote an evaluation board and a generic image. Another may include a revised carrier, display tuning, an OTA service, and a functional fixture. The lower number is not necessarily the lower project cost.

Our first pass/fail review normally looks like this:

Evidence requestedAcceptable answerWarning sign
Board revision historyDated revisions with PCN or ECN records“The factory updates parts when needed”
Android ownershipNamed BSP team and build ownerImage supplied by an external chip agent
Source and build accessDefined deliverables and reproducible instructionsBinary firmware after final payment only
Production testTest coverage, fixture photo, and sample logPower-on or visual inspection only
Component controlApproved vendor list and substitution processEquivalent parts may change without approval
Failure handlingRMA flow, analysis owner, and report formatReplacement units with no root-cause work
LifecycleSoC, memory, radio, and display supply planVerbal claim that the board is “industrial”

This table removes many candidates before anyone spends a week porting an application.

Audit the Android BSP Like a Product

The BSP is part of the product BOM even though it has no line-item unit cost. Ask the manufacturer to build the same release twice from a clean checkout. Record the manifest, toolchain or container, build configuration, signing flow, and output hashes. A supplier that cannot reproduce its current release will not maintain it reliably after the original engineer leaves.

The review should cover bootloader, kernel, device tree, vendor and ODM changes, HALs, SELinux policy, recovery, update client, and factory flashing tools. Android’s own build architecture separates board- and product-specific layers; those boundaries help only when the supplier documents where its changes live. A pile of patches applied manually by one engineer is not a release process.

For a production build, check that debugging access is intentionally controlled, verified boot and signing requirements are understood, security patches have an owner, and the update mechanism includes interrupted-update and rollback tests. If GMS is required, compatibility and licensing form a separate workstream. AOSP source availability does not automatically make a device Android compatible or grant access to Google Mobile Services.

An AOSP-based system gives an OEM control, but it also makes maintenance ownership explicit. Put supported Android versions, security response, defect severity, source delivery, and end-of-support terms in the quotation or contract.

Inspect Hardware Control, Not Just the Sample

Ask for the schematic review procedure, PCB stack-up control, critical component list, and approved alternatives. The important question is not whether an alternative DDR or eMMC exists; it is whether the alternative has already been routed, characterized, and validated in the BSP. Memory changes can affect timing and boot configuration. A Wi-Fi module change can affect antenna performance, drivers, regulatory paperwork, and labels.

For each revision, the manufacturer should be able to identify:

  • the exact BOM and assembly drawing;
  • bootloader and Android release loaded at the factory;
  • test fixture and test-limit version;
  • MAC address, serial number, and key-provisioning record;
  • rework or deviation applied to the lot;
  • sample retained for comparison.

Interface protection deserves a schematic-level review. A 40-pin header exposing UART and GPIO is not equivalent to protected RS485, CAN, or wide-input power. Define termination, isolation, ESD devices, surge level, connector retention, and application-layer access. Our industrial interface checklist is a better starting point than counting connector icons on a brochure.

Visit the Factory with a Test Plan

ISO 9001 certification is useful evidence that a quality management system exists. It is not a substitute for seeing how your board is built. Confirm the certificate scope and issuing body, then follow one actual lot through incoming inspection, storage, SMT, AOI, X-ray where applicable, rework, programming, functional test, aging if specified, final inspection, and packing.

Look for material traceability and moisture controls, but spend equal time at the functional-test station. A fixture should exercise the product features that create field risk, not merely detect catastrophic assembly faults.

Test stationWhat we expect it to catchUseful retained data
ProgrammingWrong image, bad storage, failed provisioningImage version, serial, flash result
Power testRail fault, excessive current, boot instabilityInput current and boot status
Interface fixtureDead Ethernet, USB, serial, CAN, GPIO, audioPer-port pass/fail and loopback result
Display/touch testPanel timing, backlight, touch mappingPanel ID, touch firmware, operator result
Radio testMissing module, antenna path, gross RF faultRSSI or conducted test limit
Final auditWrong label, connector, accessory, or revisionInspector, lot, and packaging version

IPC-A-610 is commonly used for electronic assembly acceptance, while J-STD-001 addresses soldered assembly process requirements. Ask which revision and product class are contractually specified. A training certificate on the wall does not prove that your acceptance criteria appear in the work instruction.

Make Compliance Ownership Explicit

A module or SBC certificate can reduce work, especially for an approved radio configuration, but it rarely transfers compliance for the complete end product. Enclosure openings, cables, power supply, display, antenna, and clock harmonics all change the test result. In the EU, the manufacturer placing the branded product on the market remains responsible for conformity assessment, technical documentation, and the declaration of conformity.

For the US, establish whether the final device follows certification or Supplier’s Declaration of Conformity procedures and whether radio modular approval conditions are preserved. Do this before freezing the enclosure and antenna. The supplier should provide existing reports and integration instructions, while the product owner and qualified lab confirm the final route.

The quotation must say who supplies samples, operates the device during testing, fixes failures, pays for retest, and maintains the technical file after a hardware change. “CE/FCC supported” is not a scope.

Normalize the Commercial Quote

Compare total landed and maintained cost, not only board price. Put non-recurring engineering, tooling, samples, fixtures, firmware customization, certification support, packaging, warranty, freight terms, and forecast commitments into one sheet. Separate one-time charges from unit price and state the volume tier and memory configuration behind every number.

Also define:

  • MOQ and price-break quantities;
  • forecast window and cancellation terms;
  • lead time for normal and constrained supply;
  • last-time-buy and PCN notice expectations;
  • warranty start point and failure allowance;
  • ownership of schematics, Gerbers, test software, and signing keys;
  • payment milestones tied to measurable deliverables.

A custom Android SBC can remove connectors and adapters from the BOM, but only if NRE and volume assumptions are visible. If the quote hides engineering effort inside an artificially low unit price, future changes become difficult to price or transfer.

Run a Gated Sample Program

Do not jump from three hand-tested samples to a large purchase order. Use gates. The engineering sample closes electrical, display, Android, and thermal risks. A revised sample verifies fixes. The pilot lot uses production files, operators, flashing flow, fixtures, labels, and packaging. Only then should the golden sample and release package be signed.

During the pilot, run the real application and peripherals. Include repeated power interruption, storage fill, network disconnect, OTA, high-load thermal soak, and a long-duration test. Record failures by serial number. “All 50 boards booted” says little if nobody tested the two CAN ports or checked whether the update survives a removed power cable.

Score suppliers only after this evidence exists. A sensible weighting is 25% BSP and update capability, 20% hardware engineering, 20% manufacturing control, 15% lifecycle and supply, 10% compliance support, and 10% commercial terms. Adjust it for the product, but do not let a small unit-price difference erase a failed technical gate.

The Decision We Would Sign Off

Choose the manufacturer that can show control of the exact product you will ship: controlled hardware files, a reproducible Android release, production test records, component-change discipline, and named engineers who can investigate a failure. A good sample is necessary. It is not sufficient.

Before approval, ask the shortlisted supplier to explain one previous board revision, one production defect, and one BSP update from detection to closure. Specific answers reveal far more than a factory presentation. If the team can show the evidence without searching for the only person who knows it, the relationship has a reasonable foundation.

Official References

Frequently Asked Questions

What should I ask an Android SBC manufacturer before ordering samples?

Ask who owns the schematics and Android BSP, which files are delivered, how board revisions are controlled, what production tests are run, which components are single-sourced, and who handles field failures and security updates.

Is ISO 9001 enough to qualify an SBC supplier?

No. ISO 9001 indicates that a quality management system exists, but it does not prove that the supplier can maintain your Android BSP, control component substitutions, test every required interface, or diagnose failures.

Should an Android SBC supplier provide source code?

At minimum, the contract should define access to the applicable kernel, bootloader, device configuration, build instructions, modifications, and license obligations. The exact delivery depends on the platform and agreement, but a binary image alone creates serious maintenance risk.

How many samples should be tested before mass production?

There is no universal number. Use engineering samples to close functional risks, then a pilot lot built with production tooling and test fixtures. The pilot must be large enough to expose assembly, flashing, thermal, and yield problems before the volume order.

Contact Silicore

Tell us about your embedded project and required specifications. We provide Android & Linux SBCs, core boards, and custom embedded systems based on Rockchip, Allwinner, NXP, and MTK SoCs.

  • 24-hour response Quick feedback on SBC specifications and compatibility
  • Engineering assistance Hardware design review, BSP customization & driver integration
  • Flexible MOQ Support for prototypes, pilot runs, and mass production
  • Comprehensive testing Function, aging, and reliability validation for industrial use
  • Custom solutions Display integration, I/O expansion, housing & thermal design
  • Global logistics EXW / FOB / DAP delivery via reliable international carriers