Masukan Adaptasi Sistem RK3588: Cakupan Android, Linux, dan OpenHarmony

Panduan Teknis

Untuk pengadaan baseline SDK board Android RK3588, periksa masukan, bukti, dan item yang belum terselesaikan di bawah ini sebelum menentukan pendekatan. Tetapkan penanggung jawab dan metode perolehan untuk dokumen yang hilang; jangan mengonfirmasi kompatibilitas atau kinerja hanya berdasarkan demonstrasi.

Apa yang Perlu Dikonfirmasi oleh Tiga Arah Proyek

Geser tabel secara horizontal untuk melihat semua kolom.

Arah Proyek	Masukan Utama	Pekerjaan yang Perlu Dirinci Terpisah
Sistem Android dan Aplikasi Perangkat	SDK Android Vendor, Board, Periferal, dan APK/SDK	Konfigurasi sistem, izin, antarmuka periferal, layanan aplikasi, penandatanganan, dan pembaruan.
BSP Linux dan Aplikasi Perangkat	Bootloader, Kernel, Device Tree, Root Filesystem, dan Periferal Target	Boot, driver, antarmuka userspace, layanan sistem, image, dan pemulihan.
Adaptasi Bertahap OpenHarmony	Source Code Tertentu, Dokumentasi Board, dan Target Build/Boot	Tentukan tahap boot minimal, layanan sistem, grafis, multimedia, dll., lalu evaluasi satu per satu.

Ini adalah tabel pembagian tanggung jawab proyek, bukan daftar kompatibilitas lintas sistem. Saat mengganti OS, SDK, atau board, cakupan catatan verifikasi yang ada harus dinilai ulang.

Data yang Dapat Disiapkan Sebelum Meminta Penawaran

• Model board lengkap, revisi perangkat keras, skema, penyimpanan, dan koneksi debugging.

• SDK atau source code, versi/nomor commit, toolchain, perintah build, dan image yang sudah ada.

• Model, antarmuka, mode target, dan status operasional saat ini untuk setiap periferal.

• Aplikasi bisnis, antarmuka, izin, input/output data, dan dependensi pihak ketiga.

• Langkah reproduksi masalah saat ini, log, frekuensi kejadian, dan tindakan perbaikan yang telah dicoba.

• Source code, patch, image, dokumentasi, dan tanggung jawab pemeliharaan yang rencananya akan diserahkan.

Dokumen yang tidak dapat disediakan harus didaftar sebagai kesenjangan (gap); kedua belah pihak perlu mengonfirmasi cara perolehannya atau menetapkan tahap penilaian. Jangan mengisi kekosongan dengan versi yang belum terverifikasi.

Menetapkan Kondisi Penerimaan yang Dapat Diuji Ulang

Ganti pernyataan umum "adaptasi sistem selesai" dengan kondisi spesifik seperti "versi tertentu pada board tertentu boot dari media tertentu, log dikumpulkan sesuai langkah, dan status layanan diverifikasi". Tampilan layar, kamera, audio, jaringan, aplikasi, pembaruan, dan operasi jangka panjang masing-masing memerlukan kondisi pengujian tersendiri; keberhasilan boot minimal tidak otomatis mencakup semua aspek tersebut.

Jika mencakup tugas NPU, lampirkan model, sampel, prapemrosesan, pascapemrosesan, dan lingkungan target secara terpisah. Kemampuan sistem untuk boot bukan bukti bahwa model telah diterapkan.

Menggunakan Kasus Existing untuk Menentukan Tahapan

Kasus OpenHarmony 6.1 RK3588 Stage-0 yang dipublikasikan mendokumentasikan validasi boot minimal tanpa antarmuka grafis pada board tertentu. Metode pemeriksaan log dan image-nya dapat menjadi referensi pengiriman bertahap, namun tidak menandakan selesainya sertifikasi grafis, multimedia, atau produksi penuh.

Integrasi aplikasi Android dapat merujuk pada Kasus SDK TTS Offline, dengan tetap memperhatikan batasan sistem, perangkat, dan pengujian yang berlaku pada kasus tersebut.

Cara Memecah Paket Kerja Selanjutnya

Jika SDK sudah tersedia tetapi periferal belum berfungsi, mulai dari Adaptasi Android atau Layanan BSP Linux. Konversi model dan integrasi inferensi masuk dalam Layanan Deployment NPU. Siapkan board, versi, antarmuka, dan input pengujian sebelum mendiskusikan cakupan pengembangan dan dasar penawaran.

Daftar Periksa Pengadaan

Geser tabel secara horizontal untuk melihat semua kolom.

Item Pemeriksaan	Masukan dan Verifikasi	Batas Keputusan
Kesesuaian Versi	Revisi hardware board, nomor commit SDK, patch, dan image yang ada harus cocok satu per satu	Chipset yang sama tidak menggantikan pemeriksaan kompatibilitas level board
Source Code dan Build	Konfirmasikan cakupan source code, toolchain, akses dependensi, dan hak penggunaan build	Catat tanggung jawab perolehan untuk konten yang hilang; jangan melengkapi dengan versi yang belum terverifikasi
Penandatanganan dan Rilis	Bedakan antara debug build, layanan penandatanganan, pembaruan, dan lisensi pihak ketiga	Private key produksi tidak wajib diserahkan kepada pengembang; sepakati mekanisme penandatanganan yang terkendali

Data Apa yang Diperlukan Sebelum Memulai?

Model board lengkap beserta revisinya, SDK Android, instruksi build, image yang ada, daftar periferal, dan log serial. Verifikasi versi dan ketersediaan dokumen terlebih dahulu; item yang hilang tetap dicatat sebagai masukan yang menunggu konfirmasi.

Bagaimana Cara Mengonfirmasi Cakupan Pengiriman dan Penerimaan?

Lakukan build dan boot pada board target di lingkungan yang disepakati mengikuti prosedur pengiriman; verifikasi versi, log, dan daftar masalah. Penanganan defect yang memblokir harus dikonfirmasi. Baseline yang dapat direproduksi tidak berarti periferal, aplikasi, stabilitas jangka panjang, atau kesiapan rilis produksi telah terpenuhi; Linux dan OpenHarmony harus dikelola sebagai proyek terpisah.

Bagi perusahaan di Shenzhen, Tiongkok, data di atas dapat dikirimkan terlebih dahulu untuk tinjauan jarak jauh. Integrasi prototipe, pengiriman sampel, pekerjaan di lokasi, dan biayanya dikonfirmasi berdasarkan proyek spesifik.

Daftar Periksa Tambahan Pengadaan Board Target Linux

Geser tabel secara horizontal untuk melihat semua kolom.

Item Pemeriksaan	Masukan dan Verifikasi	Batas Keputusan
Board dan Media	Periksa revisi board, konfigurasi penyimpanan, dan pilihan boot	Prosesor yang sama tidak menjamin konfigurasi boot identik
Komponen SDK	Daftarkan versi bootloader, kernel, device tree, root filesystem, dan toolchain	Bedakan biner vendor, source code yang dapat dimodifikasi, dan hak redistribusi
Debugging dan Pemulihan	Konfirmasikan level tegangan serial, kabel, alat pemulihan, dan akses resmi	Jangan menimpa media boot asli jika jalur pemulihan belum tersedia

Pemeriksaan tambahan ini juga berlaku untuk tinjauan baseline Linux bagi perusahaan di Tianjin, Tiongkok. Cakupan Android, Linux, dan OpenHarmony harus dikonfirmasi secara terpisah; hasil pengujian tidak dapat saling menggantikan.

Tinjau lingkup layanan dan kirimkan masukan proyek sebelum menyetujui pengembangan dan pelaksanaan. Lingkup layanan dalam teks asli berbahasa Mandarin