ROM Android: Porting

From OnnoWiki
Jump to navigation Jump to search

Beberapa tip untuk porting CyanogenMod ke device lain

Kemungkinan kita akan menemui telepon / tablet / apapun yang belum tersedia di CM.

Kemungkinan anda sebelumnya sudah perlu membuat CyanogenMod di komputer anda untuk satu atau dua device, dan anda merasa nyaman dengan proses compile-nya. Bahkan, anda masih mempunyai source code yang siap untuk menangani proyek yang besar.

Tampaknya ini adalah kesempatan besar anda :) ...


Catatan: Untuk keperluan tutorial ini, semua directory yang akan digunakan akan mengacu pada directory root source code (yaitu, tempat dimana kita menjalankan perintah "repo init"). Semua nama folder akan mengacu relatif pada roor source code.


Kebutuhan

Porting CyanogenMod ke device yang baru kemungkinan akan amat sangat mudah sekali, atau amat sangat sukar sekali, tergantung pada device tersebut, apakah dia menjalankan versi android yang terbaru atau tidak, dan tentunya keterampilan kita sebagai developer.

Akan sangat sukar melakukan porting tanpa mempunyai pengalaman membuat CyanogenMod (atau recovery) untuk device lain. Jadi sarannya, jika anda sama sekali belum pernah membuat / build CyanogenMod maka coba lah.

Selanjutnya, anda sebaiknya mulai membuat diri anda familiar dengan source code Cyanogenmod. Kemungkinan besar, sebagian besar yang kita butuhkan ada pada folder: 

/device/[vendor]/[codename]
/vendor/[vendor]/[codename]
/kernel/[vendor]/[codename]

Ada baiknya kita mempelajari seluruh struktur folder yang ada di CyanogenMod karena akan sangat bermanfaat saat kita melakukan porting.

Kumpulkan informasi tentang device kita

Sebelum kita melakukan porting, kita perlu mengumpulkan sebanyak mungkin informasi tentang device kita. Masuk ke wikipedia dan identifikasi:

  • nama produk.
  • code name
  • arsitektur
  • memory size
  • internal storage size
  • platform architecture

Simpan semua informasi ini di sebuah file untuk memudahkan mencarian. Usahakan untuk belajar sebanyak mungkin tentang device tersebut, termasuk kesamaan dengan device lain.

Banyak device secara arsitektur mirip dengan device yang sudah ada di pasar dan sudah ada porting CM-nya. Jika device baru muncul, kemungkinan kita akan menemukan kemiripan ke device lain, mungkin akan berbeda di besarnya layar atau lebih banyak memory atau beberapa perbedaan kecil lainnya. Jika kita dapat menemukan "sepupu" atau "nenek moyang" dari device kita, maka sebagian besar pekerjaan kita sudah dilakukan.

Sebagian besar informasi yang kita butuhkan kemungkinan besar tersedia online, asumsinya device tersebut telah menjalankan versi android non-CyanogenMod , kita akan memperoleh informasi tentang device tersebut. Untuk melihat file berisi informasi tersebut, device perlu di root. Kadang kala, kita dapat menemukan paket stock firmware update secara online, dan kita dapat melihat fie dari arsip file .zip.


Lihat pada device /system/build.prop

Untuk device yang sudah menjalankan Android, akan ada file /system/build.prop di device yang akan berisi informasi yang sangat bermanfaat saat kita melakukan porting. File ini berisi definisi dari berbagai parameter dan setting yang digunakan oleh Android.

Jika kita sebelumnya pernah menginstalasi adb ke komputer kita, kita dapat menggunakan perintah berikut untuk mengambil file tersebut ke komputer kita: 

adb pull /system/build.prop

Jika kita memperoleh error karena permission (ijin), maka device perlu di root untuk dapat mengakses file tersebut. Untung, ada cara lain untuk memperoleh file tersebut. Contoh, file tersebut akan ada di paket stock firmware "upgrade" yang tersebut online.

Jika kita sudah berhasil memperoleh file /system/build.prop

  • Tulis nilai dari parameter ro.product.manufacturer. Ini adalah nama vendor. [vendor] adalah nama dari manufacturer/vendor dari device. CM sudah membuat konvensi nama untuk vendor yang besar, seperti, samsung, htc, lge, dll. Perhatikan bahwa dalam directory ini, nama vendor selalu huruf kecil tanpa spasi.
  • Tulis nilai dari parameter ro.product.device . Ini adalah codename device. [codename] berhubungan dengan project code name dari device. Biasanya bukan nama sales dari device. Jika anda pernah membuat CM sebelumnya (sebaiknya, anda pernah!), anda akan familiar dengan konsep code name dari masing-masing device. Seperti vendor, codename selalu huruf kecil dan tidak ada spasi.

Catatan: kadang kala device di identifikasi dengan parameter lain, seperti ro.product.board.

Simpan baik-baik file build.prop, karena kita akan membutuhkannya nanti.

Pelajari boot.img dan recovery.img

Seperti disebutkan sebelumnya, saat kita melakukan porting, kita biasanya berharap untuk dapat menggunakan kernel yang sudah jadi yang kita yakini dapat berjalan dengan baik daripada membuat dari source code. Tergantung dari device yang kita miliki, kita mungkin perlu mengekstrak file kernel dari device. Kernel kemungkinan berbentuk sebuah fole (seperti kebanyakan device OMAP) atau digabungkan dengan ramdisk dalam partisi boot atau partisi recovery.

Sejalan dengan itu, isi dari stock ramdisk sangat menolong dan kadang kala bisa di extrak dan di lihat. Kadang kala, sebuah device membutuhkan file tertentu dari stock ramdisk agar dapat boot secara benar, load modul, dll. Biasanya, kita dapat melihat file di ramdisk dari device itu sendiri, akan tetapi biasanya kita lebih suka untuk melihat directory secara keseluruhkan.

Catatan: ramdisk adalah sekumpulan kecil file dan directory yang di load ke memory dengan kernel. Kernel kemudian akan menjalankan satu dari file di ramdisk yaitu init, yang kemudian akan menjalankan script (init.rc, init.[codename].rc, dll.) yang kemudian akan me-load sisa sistem operasi Android. ramdisk dan kernel dapat di paket bersama melalui berbagai cara menggunakan tool seperti mkbootimg, mkimage, dan cara lainya.

Kita sering kali dapat meng-ekstrak boot dan recovery image (dari file boot.img dan recovery.img) di sebuah Android device yang sudah di root menggunakan perintah dd di linux. Atau, jika kita mempunyai akses ke file update .zip dari vendor, kita seringkali dapat memperoleh file tersebut di dalamnya.

Kumpulkan source code yang tersedia

Pabrikan atau vendor dari device menggunakan android minimal harus membuat source code tersedia untuk semua berdasarkan lisensi GPS berdasarkan permohonan, termasuk (dan terutama) kernel. Anda akan sangat membutuhkan untuk memperoleh copy dari kernel source dan menyimpannya dengan baik.

Meneliti struktur partisi

Bagian penyimpanan utama untuk jangka panjang dari mobile device kita biasanya adalah sebuah -- "emmc" (embedded multimedia card) -- kira-kira seperti komputer harddisk yang di siapkan sedemikian rupa untuk mengidentifikasi dan mengisolasi wilayah yang berbeda dari data. Wilayah yang unik ini biasa di sebut partisi dan bisa menyimpan berbagai jenis data di dalanmnya. Beberapa partisi berisi data mentah -- firmware, kernel, ramdisk, dll. Lebih sering, sebuah partisi di format menggunakan file system tertentu yang dikenali oleh kernel sehingga file dan directory dapat dibaca dan di tulis ke dalanmnya.

Sebelum kita mengganti sistem operasi asli dengan CyanogenMod, sangat penting untuk memastikan struktur partisi dari device. Recovery image yang kita buat akan memerlukan informasi untuk menemukan berbagai directory Android. Terutama kita perlu mengetahui mana directory yang di berikan kepada /system, /data, /cache, dan /sdcard.

Kita ingin mengetahui partisi mana yang perlu ada, di device apa, bagaimana cara mount-nya, juga size dari partisi. Informasi ini perlu ditulis di file BoardConfig.mk di directory /vendor .

Jika anda beruntung, file recovery.fstab bisa di temukan di file recovery.img , ini akan mempercepat proses untuk mengetahui apa kemana. Juga file init.[codename].rc di ramdisk akan memiliki informasi tersebut. Lihat kalimat di atas dimana partisi di mount.

Juga, perintah: 

$ cat /proc/partitions

Dari device yang berjalan / beroperasi kita juga dapat memperoleh informasi tentang partisi. Ada baiknya lihat /proc/emmc, /proc/mounts atau /proc/mtd. Kita juga akan memperoleh beberapa informasi dari perintah mount (jalankan sebagai root).

Juga cek /cache/recovery.log atau /tmp/recovery.log.

Akhirnya, jika kita punya source code dari bootloader (seperti u-boot yang banyak digunakan di OMAP-based device), kita kemungkinan akan menemukan informasi tersebut.

HATI-HATI: pada kasus langka, seperti di HP Touchpad, digunakan virtual file system.

Set up tiga directory baru

Sekarang kita sudah mengumpulkan semua informasi tentang device kita, saatnya untuk membuat folder untuk konfigurasi device, yang berlokasi di directory berikut, relatif terhadap source directory.

  • device/[vendor]/[codename]/ -- lokasi ini berisi file instalasi yang khusus untuk device kita. Directory device/ berisi 99-100% konfigurasi maupun code yang khusus untuk device kita. Kita harus mengetahui directory ini dengan baik. Seperti di jelaskan sebelumnya, akan sangat baik untuk mengadaptasi directory dari device yang secara arsitektur sama / mirip dengan yang ingin kita porting. Contoh, cari device yang menggunakan platform yang sama.
  • vendor/[vendor]/[codename]/ -- Directory vendor/ berisi file proprietary, binary yang di backup dari device asli (atau di sediakan oleh vendor, seperti Google Nexus dan beberapa TI graphics).
  • kernel/[vendor]/[codename]/ -- folder ini berisi source kernel. Jika kita mulai melakukan porting, akan lebih mudah kalau menggunakan pre-built kernel (seperti yang ada di instalasi stock / stock rom) dari pada membuat kernel dari awal. Trik untuk melakukan itu adalah meng-ekstrak kernel keluar dari stock rom dari berbagai format yang ada, dan mempaket ulang, bersama dengan ramdisk yang baru, ke bentuk yang bisa digunakan di device kita. Ini akan berbeda dari satu device ke device lain, oleh karenanya akan sangat menolong jika kita bisa melihat device yang hampir sama dengan kita yang menggunakan arsitektur yang sama. Membuat kernel dari source sebetulnya tidak perlu dilakikan untuk semua device, tapi dalam semangat open soyrce, ini adalah langkah yang di sarankan untuk CyanogenMod.

Ada paling tidak tiga cara untuk membuat directory di atas:

Method 1: Menggunakan script mkvendor.sh untuk membuat file

Gunakan mkvendor.sh script ada di build/tools/device/ untuk secara automatis membuat directory.

Script mkvendor hanya dapat digunakan untuk device yang menggunakan file standard boot.img , menggunakan standard konvesi dan dan header Android standard. Script ini tidak jalan untuk device yang berbeda dari standard, seperti Nook Color, Touchpad, dll.

Script ini menerima tiga parameter: vendor, codename, dan file boot.img

Contoh penggunaan: 

$ ./build/tools/device/mkvendor.sh samsung i9300 ~/Desktop/i9300boot.img

Dalam contoh , samsung menunjukan vendor, i9300 menunjukan codename dan parameter terakhir path ke file boot.img yang di ekstrak dari partisi boot dengan dd atau diberikan oleh vendor dalam file .zip seperti di diskusikan di atas.

Perintah di atas akan membuat folder /device/samsung/i9300/ dalam struktur repo source CyanogenMod. Dalam folder tersebut ada file AndroidBoard.mk, AndroidProducts.mk, BoardConfig.mk, cm.mk, device_[codename].mk, kernel (binary), recovery.fstab, dll

Langkah di atas tidak akan membuat directory kernel/ . Kita perlu melakukannya nanti, saat kita sudah siap untuk membuat kernel.

Jika responds yang diberikan adalah 

"unpackbootimg not found.
Is your android build environment set up and have the host tools been built?"

pastikan anda menjalankan perintah berikut saat mensetup developer environment: 

$ make -j4 otatools

Method 2: Fork dari device yang mirip git repository

Jika anda mempunya account di GitHub http://www.github.com, ada baiknya mulai melakukan forking https://help.github.com/articles/fork-a-repo dari device yang lain / mirip, dan di rename menjadi device kita.

Pastikan kita mengikuti lisensi dari repository yang kita fork.

Method 3: buat directory dan file secara manual

Kita dapat juga mulai dengan cara membuat directory kosong dan membuat file dengan tangan. Cara ini tidak terlalu di rekomendasikan dan mungkin memrupakan cara yang paling melelahkan, tapi merupakan cara yang paling memberikan pembelajaran. Kita dapat melihat device lainnya untuk referensi dan file yang kita perlukan.

Meng-kustomsisasi file

Ada banyak file di folder device/ . Agar recovery pada device kita dapat berjalan dengan baik, kita akan mulai memfokuskan pada file / folder berikut, yaitu: 

BoardConfig.mk
device_[codename].mk
cm.mk
recovery.fstab
kernel

Langkah pertama / utama yang perlu dilakukan adalah untuk membuat recovery image berjalan di device kita sehingga percobaan untuk update .zip selanjutnya menjadi mudah sehingga kita dapat melakukan backup jika di perlukan. Langkah berikut memfokuskan pada bagaimana agar recovery image dapat dibuat dengan baik, bukan bekerja pada CM (CyanogenMod) itu sendiri. Setelah recovery berhasil dibuat dan beroperasi dengan baik, pekerjaan yang kita lakukan dapat di jadikan bagian dari CM.

Mari perhatikan file berikut:

BoardConfig.mk

File ini berisi informasi arsitektur dan build tentang arsitektur motherboard, CPU dan hardware dari device kita. Membuat file ini dengan benar sangat penting artinya.

Untuk membuat booting recovery yang mendasar, beberapa parameter perlu di set di file berikut.

Parameter berikut perlu di set secara benar di BoardConfig agar dapat meng-compile image recovery yang berjalan dengan baik:

  • TARGET_ARCH: ini adalah arsitetur device, biasanya seperti, arm atau omap3.
  • BOARD_KERNEL_CMDLINE: tidak semua device akan pass buat parameter, akan tetapi kalau device kita melalukan hal tersebut maka parameter ini harus di isi dengan benar agar boot dapat berjalan dengan baik. Kita dapat memperoleh informasi tentang ini di ramdisk.img.
  • BOARD_KERNEL_PAGESIZE: pagesize dari stock boot.img dan harus di set secara benar agar dapat boot secara benar. Nilai yang sering digunakan adalah 2048 dan 4096 dan informasi ini dapat di ekstrak dari stock kernel.
  • BOARD_BOOTIMAGE_PARTITION_SIZE: banyaknya byte yang dialokasikan ke partisi kernel image.
  • BOARD_RECOVERYIMAGE_PARTITION_SIZE: banyaknya byte yang dialokasikan ke partisi recovery image.
  • BOARD_SYSTEMIMAGE_PARTITION_SIZE: banyaknya bytes yang dialokasikan ke partisi Android system filesystem.
  • BOARD_USERDATAIMAGE_PARTITION_SIZE: banyaknya byte yang dialokasikan ke partisi Android data filesystem.

Catatan: Nilai di atas dapat di peroleh dengan mengalikan size /proc/partitions atau /proc/mtd dengan block size, biasanya 1024.

  • BOARD_HAS_NO_SELECT_BUTTON: (optional), gunakan ini jika device kita membutuhkan tombol Power untuk mengkonfirmasi pilihan di recovery.
  • BOARD_FORCE_RAMDISK_ADDRESS / BOARD_MKBOOTIMG_ARGS: (optional), gunakan ini untuk memaksakan address tertentu untuk ramdisk. Ini biasanya dibutuhkan di partisi yang besar agar ramdisk di load ke tempat yang benar. Nilai ini dapat di peroleh dari stock kernel.

device_[codename].mk

Makefile device_codename.mk berisi instruksi tentang bagaimana paket Android dibuat, dan kemana mengcopy file dan paket tertentu, atau properties tertentu yang perlu di set saat meng-compile.

File ini dapat digunakan untuk mengcopy file penting ke ramdisk saat meng-compile.


  • PRODUCT_COPY_FILES: digunakan untuk meng-copy file saat proses compile ke ramdisk, yang akan berlokasi di $OUT/recovery/root. Contoh:
$(LOCAL_PATH)/sbin/offmode_charging:recovery/root/sbin/offmode_charging \

Ini akan meng-copy binary file offmode_charging ke folder sbin dalam ramdisk.

  • PRODUCT_NAME / PRODUCT_DEVICE: digunakan untuk men-set codename yang digunakan. Nama device ini yang digunakan dengan perintah Lunch.

kernel

Ini merupakan prebuilt kernel image atau kernel yang kita buat sendiri yang digunakan untuk boot device. Format dari kernel dapat zImage atau uImage, tergantung kebutuhan arsitektur dari device kita.

cm.mk

Kita perlu mengubah ke file ini untuk di integrasikan dengan perintah lunch, brunch, dan breakfast , sehingga device kita dapat muncul dalam daftar dan di build dengan benar. Kita juga perlu men-set beberapa variable (lihat device lainnya) untuk meng-indikasikan size dari animasi slash yang digunakan, apakah ini tablet atau telepon, dll.

Beberapa dari setting ini tidak digunakan untuk build hanya untuk recovery, tapi sebaiknya kita tetap men-set dengan benar karena jika recovery dapat dibuat dan jalan, maka setting-an kita akan menjadi penting artinya.

Sebaiknya, kita lihat lagi device yang mirip dengan device kita untuk memperoleh gambaran settingan mana yang perlu di set. Cara ini mememang memerlukan intuisi.

recovery.fstab

recovery.fstab mendefinisikan file system mount point, tipe file system, dan block device untuk setiap partisi di device yang kita gunakan. File ini sangat mirip dengan /etc/fstab di sistem operasi Linux.

Contoh: 

/system		ext4		/dev/block/mmcblk0p32

Ini akan menset block device mmcblk0p32 untuk di mount di /system dengan tipe filesystem ext4

Semua mountpoint harus ada di file ini, dan ini amat sangat penting karena informasi ini karena jika tidak hal yang sangat buruk akan terjadi, seperti, recovery flash menulis ke tempat yang salah.

Tipe filesystem datamedia dapat digunakan untuk sdcard internal juga menset block device ke /dev/null.

vendorsetup.sh

vendorsetup.sh akan di panggil saat setupenv.sh di jalankan. Ini digunakan untuk menambahkan lunch non-standard yang di kombinasikan ke menu lunch.

Untuk menambahkan device kita ke menu lunch: 

add_lunch_combo cm_<codename>-userdebug

Build test recovery image

Untuk build hanya recovery, set lunch sama seperti build biasa, kemudian tulis make recoveryimage

Jika gagal (kemungkinan besar akan gagal), lihat berbagai tip untuk "dealing with build errors" di Wiki CyanogenMod.

Jika kita memiliki fastboot, kita dapat mencoba untuk menginstalasi recovery image ke partisi recovery. Ada ara lain untuk menginstalasi recovery, seperti menggunakan dd dari sistem yang di root untuk mem-flash ke tempat yang di tuju.

Tidak banyak yang perlu di jelaskan disini, yang penting pastikan recovery dapat dilakukan sebelum kita masuk / bekerja dengan CyanogenMod. Mode recovery yang 100% jalan dan reliable amat sangat penting sekali sebelum kita bekerja / build experimen di Android.


Atur recovery_ui.cpp jika dibutuhkan

Anda mungkin akan menemukan bahwa walaupun recovery image dapat jalan, beberapa tombol hardware, seperti tombol volume atau power, yang biasanya digunakan untuk scroll ke berbagai opsi, tidak bisa jalan.

Kita perlu mengatur nilai GPIO agar tombol ini dapat di kenali. Sama halnya, jika kita ingin meng-include/exclude opsi atau memodifikasi elemen UI.

Untuk itu, kita perlu membuat dan mengedit /device/[vendor]/[codename]/recovery/recovery_ui.cpp. Kita akan menemukan banyak sekali contoh untuk file ini, maupun file pendamping recovery/Android.mk yang dapat digunakan untuk membuat file tersebut, dan bagaimana cara menggunakannya.

Tip: Nilai GPIO untuk device kita bisa ditemukan di source kernel.

Letakan folder device kita di github, dan gunakan local manifest untuk secara automatic sync dengan repo sync

Ketika kita sudah memulai dengan folder device kita, kita dapat membuat account di GitHub http://github.com dan ada baiknya membaca-baca https://help.github.com/articles/creating-a-new-repository untuk menset folder kita sebagai repository public di GitHub.Ini akan menjadi kesempatan untuk belajar tentang git, dan juga source kita akan dapat di akses oleh mereka yang akan bekerjasama dengan kita.

Pada saat memberikan nama repository, gunakan format android_device_VENDOR_CODENAME, dimana VENDOR dan CODENAME menggunakan nilai dari device. Misalnya nama account GitHub kita adalah "fat-tire" dan codename device kita adalah "encore", yang dibuat oleh Barnes and Noble. Kita perlu menyebutkan nama repository kita sebagai android_device_bn_encore. Repository tersebut dapat di akses pada https://github.com/fat-tire/android_device_bn_encore. Demikian pula, kernel repository akan bernama android_kernel_bn_encore. Dia dapat di akses pada https://github.com/fat-tire/android_kernel_bn_encore.

Hal terakhir yang perlu dilakukan adalah membuat local manifest sehingga orang lain dapat menggunakan secara automatis men-download dan membuat perubahan yang ada di mereka tetap up-to-date. Berikut adalah contoh dari skenario di atas: 


<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <project name="fat-tire/android_device_bn_encore" path="device/bn/encore" remote="github" revision="cm-10.1" />
  <project name="fat-tire/android_kernel_bn_encore" path="kernel/bn/encore" remote="github" revision="cm-10.1" />
</manifest>


Catatan: attribut revision sifatnya opsional. Jika tidak ditulis, maka repo sync akan menggunakan revisi yang tertulis di <default ... /> tag di default manifest.

Setelah kita test file local manifest dapat bekerja, kita dapat berikan file tersebut ke orang lain, dan mereka akan mencoba hasil karya kita. Pada titik ini, kita perlu terus mem-push perubahan yang kita buat ke GitHub, dan mungkin perlu memberikan ijin pada yang lain untuk commit access sehingga kita dapat bekejasama mengerjakan device tersebut.

Jika anda karena suatu hal perlu mengganti atau menambahkan repository lain dari CyanogenMod, anda dapat menambahkan repository menggunakan local manifest. Setelah kita membuat semuanya berjalan dengan baik, kita dapat menggunakan Gerrit untuk men-subnmit file yang ada di repository tersebut kembali ke CyanogenMod.

Tambahkan blob ke directory vendor/

Setelah kita mempunyai recovery yang berjalan dengan baik, saatnya untuk mem-build CyanogenMod dan jalan.

Yang pertama kali perlu dilakukan adalah meletakan semua proprietary binary blob ke folder vendor/ bersama file .mk yang akan di tambahkan di build final.

Hal ini membutuhkan tiga tahap:

  1. Buat script extract-files.sh dan setup-makefiles.sh untuk mengambil blob file dari device menggunakan adb dan meletakannya di directory yang benar di bawah /vendor/ . Ada banyak contoh tersedia untuk berbagai device.
  2. Buat Makefile .mk untuk mengcopy file ke folder $OUT saat proses build dan meletakannya di tempat yang benar. Sama seperti sebelumnya, sebaiknya menggunakan contoh / pegangan device lain untuk membuat Makefile karena harusnya mirip. Sebua contoh filename adalah BoardConfigVendor.mk
  3. Pastikan bahwa Makefile yang kita buat termasuk dalam BoardConfig.mk melalui perintah seperti -include vendor/[vendor]/[codename]/BoardConfigVendor.mk. Sama seperti sebelumnya, device yang ada harusnya dapat memberikan ilustrasi bagaimana cara membuatnya.

Revisi directory device/

Karena kita sudah mempunyai directory yang dapat berjalan dengan baik, kembali dan mulai memodifikasi file di folder device/ . Seperti biasanya, gunakan device yang mirip sebagai referensi.

Kita sekarang mempunyai cara yang mudah untuk melakukan backup dan test hasil build yang kita lakukan. Oleh karena-nya kita dapat mulai melakukan perubahan-perubahan pada folder device itu sendiri, dan melihat apakah kita dapat membuat-nya boot ... Jika kita berhasil melakukannya, selanjutnya adalah masalah bagaimana membuat dan mendukung berbagai komponen dan peripheral, satu per satu.

Cari pertolongan dari pabrikan & vendor

Banyak OEM (Original Equipment Manufacturer) yang membuat device yang kita gunakan menyediakan wiki, dokumentasi, contoh source code yang dapat membantu kita dapat menyelesaikan porting. Anda akan menemukan bahwa beberapa perusahaan lebih bersahabat dengan komunitas developer di banding dengan yang lain. Ini ada beberapa EOM dan vendor beserta situs dan repository-nya yang mungkin dapat menolong.

(Daftar ini tedak lengkap)

OEM Platform Repositories/Resources
Google various Google's Git Repository , Nexus binary blobs
HTC various Dev Center
Lenovo various Lenovo Smartphones (Search your device)
LG various LG Open Source Code Distribution
Motorola various Motorola Open Source Center
Nvidia Tegra Tegra's GitWeb
Qualcomm MSM/QSD Code Aurora Forum
Samsung various Samsung Open Source Release Center
Texas Instruments OMAP www.omapzoom.com , Omappedia


Kadangkala jika kita mempunyai pertanyaan dapat mengirim e-mail ke developer atau support forum.

Menambahkan XML Overlas

Kemungkinan besar di file device_[codename].mk dari device kita, ada kalimat yang kira-kira sebagai berikut: 

DEVICE_PACKAGE_OVERLAYS := \
    device/[vendor]/[codename]/overlay

Kalimat ini pada dasarnya menset folder overlay/ yang meungkinkan kita untuk meng-override file XML yang digunakan Android framework or apps, hanya untuk device ini. Untuk melakukan hal ini, buat sebuah struktur directory yang mem-mirror path menuju XML file, mulai dari root dari source code kita. Kemudian ganti file yang ingin kita overlay.

Contoh: Misalnya kita ingin meng-override standard Android setting. Lihat file di frameworks/base/core/res/res/values/config.xml. Copy ke device/[vendor]/[codename]/overlay/frameworks/base/core/res/res/values/config.xml. Sekarang versi kita yang akan digunakan bukan yang lain. Kita hanya perlu menambahkan setting yang ingin kita override -- tidak perlu semua setting, sehingga kita hanya perlu mengubah file yang berbeda dengan default saja.

Kita dapat overlay file XML apa saja, yang bereffek pada layout, setting, preferensi, translasi dan lainnya.

Make the kernel and kernel modules build from source

If you have previously used a pre-built kernel, you may at some point want to start building the kernel from scratch.

See the instructions for how to change the BoardConfig.mk file to make CyanogenMod build the kernel and any required kernel modules automatically.

Conclusion

There's no way a single wiki page will tell you everything you need to know to do a port from beginning to end. However, hopefully you now have an understanding of how things are set up and the steps you need to take. You an always ask for help on the forums or on IRC. Others with the same device may jump in to help too.

Hopefully you'll find the process rewarding and educational. And it'll get you some street cred as well.

When you're all done, and your port works better than stock... when it's stable and shiny and marvelous and wonderful...

You may want to contribute your work upstream. Here are the instructions for how to do just that.

Good luck!

See Also


Referensi

Retrieved from "https://onnocenter.or.id/wiki/index.php?title=ROM_Android:_Porting&oldid=41394"