What to Check in a Rockchip Android BSP Before Choosing a Board

A board that boots Android and plays a video has demonstrated a starting point. It has not demonstrated that your team can rebuild, secure, update, and recover the product. A Rockchip Android BSP should be evaluated as a software delivery package before the board is selected.

The useful question is whether the supplier can deliver an image whose important behavior your team can reproduce and maintain. That includes the boot chain, kernel, vendor components, hardware interfaces, and application permissions.

This checklist is intended for engineering and purchasing reviews. It does not claim that a particular supplier image passes these checks, and it does not treat an Android version number as proof of certification or long-term support.

Ask for the identity of the delivered software

Request a release identifier, build fingerprint, Android version, API level, kernel version, security patch information, and the exact board revision. Record which RAM, storage, panel, and peripheral variants are covered.

Keep a copy of the factory image and its hash. If a reported defect cannot be tied to a specific image, the supplier and application team can spend days comparing different builds without realizing it.

On a device available through authorized ADB access, these read-only commands collect useful starting information:

adb shell getprop ro.build.fingerprint
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch
adb shell uname -a

These values identify reported software properties. They do not independently prove that every required security fix is present. Compare them with the supplier’s release notes and patch evidence rather than accepting the displayed date as the entire security review.

Rebuild before hardware selection becomes permanent

Request the source manifest, pinned revisions, toolchain requirements, binary dependencies, build commands, and image-packaging procedure. Clarify which components are delivered as source and which remain supplier-provided binaries.

Have an engineer build from a clean environment using only the documented inputs. Flash the resulting image to the target board and repeat the essential functional tests. A successful build on the supplier’s existing workstation is weaker evidence than a repeatable build on a separate machine.

Separate development configuration from production configuration. Debugging access, privileged tools, test keys, permissive policies, and factory utilities should have explicitly defined roles and removal or restriction procedures.

The custom Android work plan should allocate ownership for every local modification. A patch that is essential to the product needs a maintainer and a regression test, not merely a place in an email attachment.

Test the interfaces your application actually uses

Create a matrix linking each physical interface to its driver, Android access path, and application test. A kernel device node appearing at boot is not the same as a usable, permission-controlled application API.

For serial, CAN, GPIO, or other custom hardware, verify access with the production application identity and security policy. A demonstration performed as root can conceal work still needed in HALs, services, permissions, or SELinux rules.

Display tests should cover rotation, composition, touch mapping, brightness, and resume behavior. Camera tests should use the intended sensor, mode, and buffer path. Include communication and storage load during those tests.

Ask how the supplier handles replacement components. Changing a touch controller or Ethernet PHY may require a driver or configuration change even when the board retains its commercial model name.

Review security as a maintained process

A production image needs a defined boot trust policy, release signing process, credential-provisioning method, and update authority. The correct implementation depends on the product and threat model, so document those assumptions.

Ask who monitors Android, kernel, and vendor vulnerabilities; who decides applicability; and how a fix reaches deployed units. Android security bulletins cover several layers of the platform, while a board image may also contain third-party services outside those bulletins.

Verify the intended SELinux state and investigate required exceptions. Switching the whole image to permissive mode may simplify a prototype but should not become the default solution to application integration problems.

Separate AOSP functionality from Google services. If the product requires GMS or a particular certification, obtain a written, applicable plan. A supported Android release alone does not establish the right to ship Google applications or the completion of compatibility testing.

Demonstrate updates and recovery together

An update design should specify what is signed, what is replaced, how compatibility is checked, and what happens when the installation fails. Partition layout and storage capacity constrain those choices.

Test an approved interrupted-update scenario on development units. Verify whether the device boots an intact image, enters a usable recovery path, or needs a factory tool. Preserve application data according to a stated policy.

Rollback needs application consideration. A database migrated by a new application may not work with the previous application even when the operating system rolls back successfully. Define supported version combinations and data recovery behavior.

The hardware watchdog belongs in this discussion. It should not repeatedly reset a device while a legitimate update is still making progress, and an update failure should not leave supervision disabled indefinitely.

Turn support promises into deliverables

Ask for response times and escalation routes for a blocking defect. Clarify whether support includes investigation, source changes, regression testing, and a signed release, or only access to a download directory.

Price custom work separately when necessary. A vague promise of lifetime support is less useful than a bounded agreement identifying supported branches, responsibilities, and how engineering changes are funded.

Use a small acceptance project before the volume order

Preserve factory-provisioning inputs separately from generic software images. Serial numbers, network addresses, device credentials, and calibration values may need to survive an update or factory reset under different rules. Request a documented partition and data-retention map. Then verify the approved reset and recovery paths on representative units so that a service operation cannot silently duplicate identities or discard required calibration.

Select the highest-risk functions and demonstrate them on the proposed production configuration. Build, flash, launch the application, exercise peripherals, update, and recover. Keep the logs with image and board identifiers.

The SBC manufacturer decision should incorporate that evidence alongside price and lead time. Hardware availability does not remove software delivery risk.

Approve the board when your team knows how the image is produced, which dependencies remain external, and how field failures will be repaired. Those answers make the BSP part of a maintainable product rather than a demonstration that only its original developer can reproduce.

Technical basis: Rockchip open-source platform documentation, Android Open Source Project security bulletins, and supplier-specific release artifacts.