RK3588 system adaptation inputs: Android, Linux and OpenHarmony scope

Engineering guide

For an RK3588 Android board SDK baseline procurement, check the inputs, evidence and unresolved items below before selecting an approach. Assign owners and acquisition methods for missing documents; a demonstration alone does not establish compatibility or performance.

What the three project directions need to confirm

Swipe the table horizontally to view all columns.

Direction	Main inputs	Work to scope separately
Android systems and device applications	Vendor Android SDK, board, peripherals and APK/SDK	System configuration, permissions, peripheral interfaces, application services, signing and updates.
Linux BSP and device applications	Bootloader, kernel, device tree, root filesystem and target peripherals	Boot, drivers, userspace interfaces, services, images and recovery.
Staged OpenHarmony adaptation	Specified source, board documentation and build/boot targets	Assess minimal boot, services, graphics and multimedia as separate stages.

This is a project-responsibility table, not a cross-system compatibility list. Reassess existing verification records when the OS, SDK or board changes.

Inputs to prepare before requesting a quotation

• Full board model, revision, schematic, storage and debugging connections.

• SDK/source, version or commit, toolchain, build commands and existing images.

• Peripheral models, interfaces, target modes and current working states.

• Applications, interfaces, permissions, inputs/outputs and third-party dependencies.

• Reproduction steps, logs, frequency and attempted remedies for existing failures.

• Agreed source, patches, images, documentation and maintenance responsibilities.

List unavailable documents as gaps and agree how to obtain them or define an assessment stage. Do not fill gaps with unverified versions.

Define repeatable acceptance conditions

Replace “system adaptation complete” with conditions such as booting the specified version on the specified board from the specified medium and checking logs and services using documented steps. Display, camera, audio, networking, applications, updates and endurance each need their own conditions; minimal boot does not cover them automatically.

For NPU work, add the model, samples, preprocessing, postprocessing and target environment. A bootable system does not establish model deployment.

Use case records to understand project stages

The original Chinese OpenHarmony RK3588 Stage-0 case documents a limited headless boot stage. Its logging and image checks illustrate staged delivery; they do not establish full graphics, multimedia or production certification.

The original Chinese offline TTS SDK case illustrates Android application integration within the case’s own system, device and test boundaries.

Split subsequent work packages

For an existing SDK with unresolved peripherals, review Android adaptation or the Linux BSP service. Model conversion and inference integration belong to the NPU service. These links lead to original Chinese scopes. Prepare board, version, interface and test inputs before assessing development scope and cost.

Procurement checklist

Swipe the table horizontally to view all columns.

Item	Inputs and checks	Decision boundary
Version matching	Match the board revision to the SDK commit, patches and existing image	The same processor does not establish board compatibility
Source and build access	Confirm source scope, toolchain, dependency access and build rights	Assign owners for missing inputs rather than substituting unverified versions
Signing and release	Separate debug builds, signing services, updates and third-party licenses	Production private keys need not be handed to the developer; agree a controlled signing process

What inputs are needed before starting?

The full board model and revision, Android SDK, build instructions, existing images, peripheral list and serial logs. Check document versions and availability first and retain missing items as unresolved inputs.

How should delivery and acceptance be defined?

Build and boot the target board in the agreed environment using the delivered procedure; verify versions, logs and issues, and agree treatment of blocking defects. A reproducible baseline does not establish peripheral, application, endurance or production readiness; scope Linux and OpenHarmony separately.

Enterprises in Shenzhen, China, can submit these inputs for remote review. Agree prototype integration, sample shipment, site work and associated costs for the specific project.

Additional Linux target-board procurement checks

Swipe the table horizontally to view all columns.

Item	Inputs and checks	Decision boundary
Board and medium	Check board revision, storage configuration and boot selection	The same processor does not establish identical boot configuration
SDK components	List bootloader, kernel, device-tree, root-filesystem and toolchain versions	Distinguish vendor binaries, editable source and redistribution rights
Debug and recovery	Confirm serial levels, wiring, recovery tools and authorized access	Do not overwrite the original boot medium without a recovery path

These additional checks support Linux baseline reviews for enterprises in Tianjin, China. Scope Android, Linux and OpenHarmony separately; their test results are not interchangeable.

Review the service scope and submit the project inputs before agreeing on development and delivery. Original Chinese service scope