Set-Top-Box dan percobaan dengan Android di wadah LXC

Bagaimana kebutuhan aneh muncul untuk menjalankan Android dalam wadah Linux, dan apa yang terjadi

Latar belakang


Menjalankan Android dalam wadah LXC, menurut saya, adalah keputusan logis jika Anda ingin memiliki transparansi dan keandalan Bare Linux dan menggunakan potensi besar aplikasi Android pihak ketiga yang baik (dan tidak begitu baik). Juga, konfigurasi ini menarik sebagai platform untuk men-debug gambar AOSP Anda sendiri dalam kondisi sedekat mungkin dengan pertempuran.
Untuk percobaan, dipilih set-top box Cina progresif dan murah berdasarkan 64-bit ARMv8 dari Amlogic S905x dipilih (CPU - 4 core, RAM - 2GB, MMC - 8GB). Juga, argumen yang baik (dibandingkan dengan vendor lain) adalah basis kode di OpenSource dan keberadaan driver kernel kernel sumber untuk Mali-450. Perpustakaan pengguna-ruang Mali hari ini di domain publik di situs web resmi ARM Limited. Pustaka akses biner untuk Linux-FB, Linux-Wayland, dan Android.

Tujuan utama percobaan adalah aplikasi bioskop online dan aplikasi untuk bekerja dengan hosting media jaringan. Misalnya, dengan Youtube di Linux, masalah langsung dimulai. Pertama: metode peretas untuk mendapatkan tautan ke konten dengan mem-parsing skrip JS dan menghasilkan tanda tangan (sebelumnya diimplementasikan dalam minitube dari Tordini dan di youtube-dl) mulai mogok secara teratur karena perjuangan Google tanpa ampun dengan metode perayapan iklan. Kedua: resolusi maksimum konten adalah 720p - lebih banyak Google-API tidak mengeluarkan. Ketiga: WebKit telah kehilangan dukungan normal dan baru-baru ini hanya didukung oleh sekelompok kecil penggemar. Nasib yang sama menimpa port Qt-nya. Akibatnya, pada satu titik, halaman youtube / tv menolak untuk bekerja, mengutip usia mesin web. Nah, pada akhirnya, dia mengemukakan kejutan WebEngine (Qt-Chromium). Ternyata keindahan ini tidak mendukung akselerasi perangkat keras. Pengecualian hanya dibuat untuk port Android-nya, dan cabang VAAPI marginal di Linux. Jalan buntu. Secara umum, saya tidak menemukan cara sederhana untuk mengaktifkan decoding video akselerasi perangkat keras untuk Chromium di Linux. Menerapkan VAAPI untuk Amlogic tampak seperti pekerjaan yang sulit dan tidak berguna bagi saya. Saya juga merasakan lada plugin - sayangnya PPAPI tidak mengizinkan memutar video layar.

Android


Mengapa tidak menjalankan Android dalam sebuah wadah? Proyek Anbox menginspirasi prestasi tersebut. Sebuah studi menyeluruh tentang Anbox telah menunjukkan bahwa itu tidak cocok untuk kita. Tapi idenya jelas. Artikel oleh penulis lain mengklaim bahwa menjalankan Android dalam sebuah wadah adalah tugas yang bodoh. Tetapi pada kenyataannya, semuanya ternyata jauh lebih rumit. Dengan hanya mengkonfigurasi file konfigurasi, kami tidak bisa turun.

Jadi, saya mengumpulkan LXC dan menginstalnya di sistem. Tes konfigurasi kernel mengungkapkan masalah: Anda perlu mengaktifkan dukungan namespace. Karena platform ini built-in, segala macam hal yang tidak perlu dinonaktifkan. Saya harus mengidentifikasi ini tidak perlu.

Tes pertama memeriksa Busybox di wadah. Setelah memastikan semuanya bekerja, saya mulai bereksperimen.

Tampilan awal adalah /var/lib/lxc/abox.conf:

lxc.rootfs = /var/lib/lxc/abox/rootfs lxc.rootfs.backend = dir lxc.utsname = abox lxc.pts = 1024 lxc.cap.drop = mac_admin mac_override 

Unduh tangan Cina rampasan AOSP 6.0.19. Ini berbeda dari versi vanilla dengan kehadiran launcher yang normal, dipertajam oleh surfacelinger yang distash dan hard-patched dengan dukungan untuk beberapa fitur platform perangkat keras Amlogic. Vanilla AOSP selanjutnya juga diuji.

Sedikit keluar dari topik: Cina, mengadaptasi perangkat lunak, meludahi semua aturan yang ditetapkan oleh komunitas. Sebagai contoh, kernel 3.14.29. Nomor rilis kernel diam ini digunakan pada hampir semua perangkat keras pada prosesor Amlogic S8xx dan S9xx. Tapi, hampir selalu, mereka sangat berbeda satu sama lain, hingga ketidakcocokan lengkap modul lama dengan gambar baru dan sebaliknya. Tampaknya inti dikoreksi sesuai dengan prinsip: "secepat mungkin masuknya produk ke pasar". Kode ini tidak hanya kotor - kualitasnya menjijikkan. Mengubah konfigurasi biasanya menyebabkan kesalahan saat mengkompilasi atau menautkan gambar atau modul. Android yang ditambal memiliki kualitas yang sama, dan prinsip-prinsip adaptasi serupa. Hampir semua rekomendasi dari tim AOSP diabaikan.

Nah ke mana harus pergi! Kami mengumpulkan.

Percobaan No. 1 Instal gambar dalam wadah, jalankan. Tidak bekerja Analisis menunjukkan bahwa tidak ada objek kernel: binder dan ashmem. Kami menambahkan modul kernel.

Percobaan No. 2 Kita mulai lagi. Installd lumpuh. Ternyata pengikat aslinya tidak tahu tentang ruang nama. Tarik binder dari Anbox.

Percobaan nomor 3 dimulai dan segera reboot. Ternyata init ingin SELinux dan menolak untuk bekerja tanpanya.

Percobaan No. 4 Nyalakan SELinux. Kami mendapatkan banyak masalah untuk sistem host. Saya harus mematikannya, setidaknya untuk sekarang - sampai esensi dan teori dari proses itu diklarifikasi. SELinux juga dapat dinonaktifkan pada baris perintah saat memuat kernel, tapi saya masih tidak mengerti bagaimana cara mengirimkan parameter ke wadah. Saya harus masuk ke sumber init dan secara kasar memperbaiki perilakunya. Ini adalah intervensi bedah pertama dan terakhir yang kembali kepada saya nanti.

Percobaan No. 5 Proses booting mencapai zygote. Dalam log, bersumpah dari kernel pada init UID. Di binder (dan binder dari Anbox), UID proses pemilik mudah dibandingkan dengan kesatuan. Satu-satunya cara adalah menonaktifkan cek, terutama karena cek ini tidak ada artinya dalam wadah.

Percobaan No. 6 Konflik yang terkait dengan berbagi akses ke manajemen peralatan muncul. Saya mengomentari kontrol USB dan Bluetooth di skrip init. Saya menghapus semua entri dari fstab, dan melarang pemasangan dan verifikasi semua media dalam skrip. Sekarang tambahkan kartu mount ke konfigurasi wadah. Ini hanya berisi satu baris. Direktori /mnt/lxc.data dipasang pada host di partisi MMC nyata.

 lxc.mount.entry = /mnt/lxc.data data auto rw,bind 0 0 

Percobaan No. 7 Bola memantul muncul di layar, memuat membutuhkan waktu lama, karena gambar Android dipasang pada NFS, dan dexx juga dihasilkan di direktori / data. Memuat ulang jauh lebih cepat. Dan akhirnya, peluncur muncul.
Kami akan menganggap ini sebagai upaya terakhir, karena, secara umum, semuanya berfungsi dan Anda harus menyelesaikan detailnya.

Jaringan tidak berfungsi, ia bekerja lebih tepatnya, tetapi beberapa aplikasi mengevaluasi kinerjanya dengan keadaan antarmuka jaringan. Tangan bengkok, singkatnya. Untuk menghilangkan kelemahan ini pada host, kami menaikkan network bridge (jembatan) dan antarmuka virtual (veth).

 lxc.network.type = veth lxc.network.flags = up lxc.network.name = eth1 lxc.network.link = br0 lxc.network.veth.pair = veth-01 lxc.network.ipv4 = 10.0.0.10/24 lxc.network.ipv4.gateway = 10.0.0.1 lxc.network.hwaddr = 00:FE:CD:BA:09:87 

Anda juga perlu menaikkan server DHCP, jika tidak akan ada masalah dengan DNS. Sayangnya, Android tidak menganalisis resolv.conf dan lokasinya di sistem file tidak memainkan peran apa pun. Anda dapat mengkonfigurasi koneksi jaringan secara manual, tetapi jika Anda menghapus data dari bagian data, semua pengaturan akan diatur ulang.

Ringkasan


Semua aplikasi stok berfungsi. Dengan diinstal dari pasar ada masalah. Sebagai contoh: Youtube.tv versi 3 menuntut untuk memperbarui kerangka layanan Google, setelah itu sistem macet. Masalah dengan keystore muncul (belum terselesaikan). TEE juga dinonaktifkan sementara, jadi widevine tidak berfungsi. Mainan dan aplikasi berfungsi dengan baik tanpa persyaratan perangkat keras khusus. Chrome memutar video HTML5 dengan decoder perangkat lunak, menolak untuk menghubungkan decoder perangkat keras. Pada kesempatan ini, ada pendapat tentang AOSP yang dibengkokkan oleh Cina. Tapi vanilla AOSP meluncurkan peluncur dengan layar sentuh - tidak mungkin untuk mengendalikan distacha.

Kata penutup


Dalam waktu dekat - untuk membuat peluncur untuk meluncurkan aplikasi Android langsung dari Linux. Contoh dari ini tersedia di sumber pemohon wpa. Anda juga dapat mengintip bagaimana hal ini dilakukan di Anbox.

Terima kasih atas perhatian anda!

Penambahan 1


Suatu hari saya memeriksa skalabilitas aplikasi Qt. Awalnya, aplikasi klien IPTV ditulis dalam QML untuk Linux. Pemain bekerja melalui plugin QtMultimedia. Selama kompilasi, dependensi yang bermasalah muncul. Untungnya, semuanya terbatas pada QtDbus, yang tidak ada di Android. Saya masih tidak bisa mengerti mengapa Android perlu menemukan kembali pengikat roda. Apa yang tidak disukai pengembang DBus? Bahwa itu berfungsi di ruang pengguna? Atau pertimbangan lisensi?
DBus terputus. Ini tidak menyakitkan, karena saluran diperlukan untuk sedikit fungsionalitas yang terkait dengan sistem operasi. Gathered apk. Tidak ada kesulitan dengan perakitan, karena saya menggunakan QtCreator (dan saya merekomendasikannya kepada Anda).
Di AOSP, saya harus menggambar jembatan Mediaplayer - pewaris dari android :: MediaPlayerInterface. Metode setDataSource () dan stop () diimplementasikan di dalamnya. Colokan dibuat untuk yang lainnya. setDataSource memiliki tiga antarmuka. Itu diperlukan untuk mengimplementasikan saja:
 setDataSource(const sp<IMediaHTTPService> &httpService, const char *uri, const KeyedVector<String8, String8> *headers) 


Jika Anda ingin memutar file dari media, Anda harus mengotak-atik
 setDataSource(int fd, int64_t offset, int64_t length) 

Nama file harus diperoleh melalui "/ proc / self / fd /" + fd;

Setelah instalasi, aplikasi diterima dan siaran pergi. Hebat! Saya mengharapkan banyak masalah, tetapi hampir tidak ada. Terima kasih kepada pengembang Qt dan QtCreator untuk pekerjaan yang hebat dan bermanfaat!
Akibatnya, saya mendapat banyak: pemain daemon tuan rumah. Dalam wadah, ada program klien dan panggilan siaran android :: Mediaplayer ke tuan rumah. Bundel bekerja melalui soket UDP.

Source: https://habr.com/ru/post/id413809/


All Articles