Engineering guide
For an RK3588 Android board SDK baseline, use the sequence below to retain reproducible inputs, actions and exception evidence. This is an implementation method; actual interface names, commands and parameters depend on the target device and version documentation.
Implementation and exception checks
Swipe the table horizontally to view all columns.
| Step | Action and evidence | Exception handling |
|---|---|---|
| Record the baseline | Freeze the board, SDK, toolchain, configuration and build commands | Retain patches and dependency gaps; record changes during troubleshooting |
| Build and image | Build using the vendor instructions and retain logs, artifacts and checksums | A checksum identifies an artifact; separate builds are not assumed to be byte-identical |
| Flash and boot | Confirm backups, target storage and recovery before capturing serial boot logs | Preserve failure logs; a visible desktop does not establish peripheral or application readiness |
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.
Review the service scope and submit the project inputs before agreeing on development and delivery. Original Chinese service scope
Online
Phone
WeChat
Top