Difference between revisions of "ROM Android: Porting"

From OnnoWiki
Jump to navigation Jump to search
 
(37 intermediate revisions by the same user not shown)
Line 67: Line 67:
 
=== Pelajari <code>boot.img</code> dan <code>recovery.img</code> ===
 
=== Pelajari <code>boot.img</code> dan <code>recovery.img</code> ===
  
−
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.
+
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 file (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.
 
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.
Line 77: Line 77:
 
=== Kumpulkan source code yang tersedia ===
 
=== 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.
+
Pabrikan atau vendor dari device menggunakan android minimal harus membuat source code tersedia untuk semua berdasarkan lisensi GPL berdasarkan permohonan, termasuk (dan terutama) kernel. Anda akan sangat membutuhkan untuk memperoleh copy dari kernel source dan menyimpannya dengan baik.
  
 
=== Meneliti struktur partisi===
 
=== Meneliti struktur partisi===
Line 111: Line 111:
 
* <code>vendor/[vendor]/[codename]/</code> -- Directory <code>vendor/</code> berisi file proprietary, binary yang di backup dari device asli (atau di sediakan oleh vendor, seperti Google Nexus dan beberapa TI graphics).
 
* <code>vendor/[vendor]/[codename]/</code> -- Directory <code>vendor/</code> berisi file proprietary, binary yang di backup dari device asli (atau di sediakan oleh vendor, seperti Google Nexus dan beberapa TI graphics).
  
−
* <code>kernel/[vendor]/[codename]/</code> -- the kernel source goes here. When you first start your porting effort, you may wish to simplify things by using a pre-built kernel (such as the one that came with the stock installation) rather than building the kernel from scratch. The trick to that will be extracting the kernel out of the stock system from whatever format it may be in, and then re-packaging it, along with a new ramdisk, into a form that your device can use. This can vary from device-to-device, so it may again be helpful to look at similar devices to yours that use a similar architecture. Building the kernel from source is not strictly necessary for every device, but in the spirit of open source, it is the preferred practice for CyanogenMod.  See [[Doc:_integrated_kernel_building|here]] for a detailed discussion about how CyanogenMod builds the kernel source from scratch.
+
* <code>kernel/[vendor]/[codename]/</code> -- 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.
  
−
There are at least three methods to generate these directories:
+
Ada paling tidak tiga cara untuk membuat directory di atas:
  
−
===Method 1:  Use <code>mkvendor.sh</code> to generate skeleton files===
+
===Method 1:  Menggunakan script <code>mkvendor.sh</code> untuk membuat file===
  
−
Use the <code>mkvendor.sh</code> script in <code>build/tools/device/</code> to automatically generate the directories.
+
Gunakan <code>mkvendor.sh</code> script ada di <code>build/tools/device/</code> untuk secara automatis membuat directory.
  
−
{{note|note=The <code>mkvendor</code> script only works with devices that use a standard <code>boot.img</code> file, using the standard Android conventions and headers. It won't work for devices that deviate from this standard (Nook Color, Touchpad, etc.).}}
+
Script <code>mkvendor</code> hanya dapat digunakan untuk device yang menggunakan file standard <code>boot.img</code> , menggunakan standard konvesi dan dan header Android standard. Script ini tidak jalan untuk device yang berbeda dari standard, seperti Nook Color, Touchpad, dll.
  
−
This script accepts three parameters: '''vendor''', '''codename''', and a <code>boot.img</code> file.
+
Script ini menerima tiga parameter: '''vendor''', '''codename''', dan file <code>boot.img</code>
  
−
Example usage:
+
Contoh penggunaan:
  
 
  <code>$ ./build/tools/device/mkvendor.sh samsung i9300 ~/Desktop/i9300boot.img</code>
 
  <code>$ ./build/tools/device/mkvendor.sh samsung i9300 ~/Desktop/i9300boot.img</code>
  
−
In the above example, <code>samsung</code> represents the '''vendor''', <code>i9300</code> represents the '''codename''' and the last parameter is the path to the <code>boot.img</code> file that was extracted from the boot partition with <code>dd</code> or provided by the vendor in an update .zip as discussed above.
+
Dalam contoh , <code>samsung</code> menunjukan '''vendor''', <code>i9300</code> menunjukan '''codename''' dan parameter terakhir path ke file <code>boot.img</code> yang di ekstrak dari partisi boot dengan <code>dd</code> atau diberikan oleh vendor dalam file .zip seperti di diskusikan di atas.
  
−
The command above should  create a <code>/device/samsung/i9300/</code> folder within your CyanogenMod source repo structure.  And inside the folder, the files <code>AndroidBoard.mk</code>, <code>AndroidProducts.mk</code>, <code>BoardConfig.mk</code>, <code>cm.mk</code>, <code>device_[codename].mk</code>, <code>kernel</code> (the binary), <code>recovery.fstab</code>, etc.
+
Perintah di atas akan membuat folder <code>/device/samsung/i9300/</code> dalam struktur repo source CyanogenMod.  Dalam folder tersebut ada file <code>AndroidBoard.mk</code>, <code>AndroidProducts.mk</code>, <code>BoardConfig.mk</code>, <code>cm.mk</code>, <code>device_[codename].mk</code>, <code>kernel</code> (binary), <code>recovery.fstab</code>, dll
  
−
This will not build the <code>kernel/</code> directory. You will need to do that later, when you are ready to build the kernel.
+
Langkah di atas tidak akan membuat directory <code>kernel/</code> . Kita perlu melakukannya nanti, saat kita sudah siap untuk membuat kernel.
  
−
{{note|note= If it returns the message "unpackbootimg not found. Is your
+
Jika responds yang diberikan adalah
−
android build environment set up and have the host tools been built?" please be sure that you run the following command during setting up the developer environment:
 
  
−
<code>$ make -j4 otatools</code> }}
+
  "unpackbootimg not found.
 +
Is your android build environment set up and have the host tools been built?"
  
−
=== Method 2: Fork a similar device's git repository ===
+
pastikan anda menjalankan perintah berikut saat mensetup developer environment:
  
−
If you've got a [http://www.github.com GitHub] account, you might want to start by [https://help.github.com/articles/fork-a-repo forking] another, similar device, and then rename it for your device.  See the [[Doc:_porting_intro#Put_your_device_folder_in_github.2C_and_use_a_local_manifest_to_automatically_sync_it_with_repo_sync|section on setting up github]] for a discussion on how to name your repository.
+
<code>$ make -j4 otatools</code>
  
−
Always be sure you're compliant with the license of any repository you fork.
+
=== Method 2: Fork dari device yang mirip git repository ===
  
−
=== Method 3: create the directories and files manually ===
+
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.
  
−
You can always start with an empty directory and start creating the files by hand.  This is the least recommended and perhaps the most tedious method, but it may be the most instructive.  You can look at other devices for reference on what files you need.
+
Pastikan kita mengikuti lisensi dari repository yang kita fork.
  
−
== Customize the files  ==
+
=== Method 3: buat directory dan file secara manual ===
  
−
There are many files in the <code>device/</code> folders.  We will start by focusing on four files <code>BoardConfig.mk</code>, <code>device_[codename].mk</code>, <code>cm.mk</code>, <code>recovery.fstab</code>, and <code>kernel</code> to get recovery working for your device.
+
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.
  
−
{{tip|heading=Start with the recovery!|tip=The first major step is to get a working recovery image for your device so that testing subsequent update.zips is easy and so that you can do backups if necessary. These next few steps will therefore focus more on getting a working recovery than getting CM itself to work.  Once the recovery is built and operating safely, the work you've done for it will apply directly to the CM part.}}
+
== Meng-kustomsisasi file ==
  
−
Lets examine each of these files:<br />
+
Ada banyak file di folder <code>device/</code> . Agar recovery pada device kita dapat berjalan dengan baik, kita akan mulai memfokuskan pada file / folder berikut, yaitu:
 +
 
 +
<code>BoardConfig.mk</code>
 +
<code>device_[codename].mk</code>
 +
<code>cm.mk</code>
 +
<code>recovery.fstab</code>
 +
<code>kernel</code>
 +
 
 +
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:
  
 
===<code>BoardConfig.mk</code>===
 
===<code>BoardConfig.mk</code>===
  
−
This file contains vital architectual and build information about the architecture of your device's motherboard, CPU, and other hardware. Getting this file right is essential.
+
File ini berisi informasi arsitektur dan build tentang arsitektur motherboard, CPU dan hardware dari device kita. Membuat file ini dengan benar sangat penting artinya.
  
−
To get a basic recovery booting, a few parameters need to be set in this file.
+
Untuk membuat booting recovery yang mendasar, beberapa parameter perlu di set di file berikut.
  
−
The following parameters must be set properly in <code>BoardConfig</code> to compile a working recovery image:
+
Parameter berikut perlu di set secara benar di  <code>BoardConfig</code> agar dapat meng-compile image recovery yang berjalan dengan baik:
  
−
*'''TARGET_ARCH''': this is the architecture of the device it is usually something like '''arm''' or '''omap3'''.
+
*'''TARGET_ARCH''': ini adalah arsitetur device, biasanya seperti, '''arm''' atau '''omap3'''.
−
*'''BOARD_KERNEL_CMDLINE''': not all devices pass boot parameters however if your device does this '''must''' be filled out properly in order to boot successfully. You can find this information in the <code>ramdisk.img</code>.
+
*'''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 <code>ramdisk.img</code>.
−
*'''BOARD_KERNEL_PAGESIZE''': the pagesize of the stock <code>boot.img</code> and must be set properly in order to boot. Typical values for this are '''2048''' and '''4096''' and this information can be extracted from the stock kernel.
+
*'''BOARD_KERNEL_PAGESIZE''': pagesize dari stock <code>boot.img</code> 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''':   the number of bytes allocated to the kernel image partition.
+
*'''BOARD_BOOTIMAGE_PARTITION_SIZE''': banyaknya byte yang dialokasikan ke partisi kernel image.
−
*'''BOARD_RECOVERYIMAGE_PARTITION_SIZE''': the number of bytes allocated to the recovery image partition.
+
*'''BOARD_RECOVERYIMAGE_PARTITION_SIZE''': banyaknya byte yang dialokasikan ke partisi recovery image.
−
*'''BOARD_SYSTEMIMAGE_PARTITION_SIZE''':  the number of bytes allocated to the Android system filesystem partition.
+
*'''BOARD_SYSTEMIMAGE_PARTITION_SIZE''':  banyaknya bytes yang dialokasikan ke partisi  Android system filesystem.
−
*'''BOARD_USERDATAIMAGE_PARTITION_SIZE''': the number of bytes allocated to the Android data filesystem partition.
+
*'''BOARD_USERDATAIMAGE_PARTITION_SIZE''': banyaknya byte yang dialokasikan ke partisi Android data filesystem.
−
{{note|note=The above information can be obtained by multiplying the size from <code>/proc/partitions</code> or <code>/proc/mtd</code> by the block size, typically '''1024'''.}}
+
 
−
*'''BOARD_HAS_NO_SELECT_BUTTON''': (optional), use this if your device needs to use its '''Power''' button to confirm selections in recovery.
+
Catatan: Nilai di atas dapat di peroleh dengan mengalikan size <code>/proc/partitions</code> atau <code>/proc/mtd</code> dengan block size, biasanya '''1024'''.
−
*'''BOARD_FORCE_RAMDISK_ADDRESS / BOARD_MKBOOTIMG_ARGS''': (optional), use these to force a specific address for the ramdisk. This is usually needed on larger partitions in order for the ramdisk to be loaded properly where it's expected to exist. This value can be obtained from the stock kernel. The former is deprecated as of Android 4.2.x and the latter will now be used in 4.2.x and beyond.
+
 
 +
*'''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.
  
 
===<code>device_[codename].mk</code>===
 
===<code>device_[codename].mk</code>===
  
−
The <code>device_codename.mk</code> makefile contains instructions about which Android packages to build, and where to copy specific files and packages, or specific properties to set during your compilation.
+
Makefile <code>device_codename.mk</code> berisi instruksi tentang bagaimana paket Android dibuat, dan kemana mengcopy file dan paket tertentu, atau properties tertentu yang perlu di set saat meng-compile.
  
−
This file can be used to copy vital files into the ramdisk at compilation time.
+
File ini dapat digunakan untuk mengcopy file penting ke ramdisk saat meng-compile.
  
−
*'''PRODUCT_COPY_FILES''': used to copy files during compilation into the ramdisk, which will be located at <code>$OUT/recovery/root</code>.
+
 
−
Example:
+
* '''PRODUCT_COPY_FILES''': digunakan untuk meng-copy file saat proses compile ke ramdisk, yang akan berlokasi di <code>$OUT/recovery/root</code>. Contoh:
  
 
  <code>$(LOCAL_PATH)/sbin/offmode_charging:recovery/root/sbin/offmode_charging \</code>
 
  <code>$(LOCAL_PATH)/sbin/offmode_charging:recovery/root/sbin/offmode_charging \</code>
  
−
This will copy the file offmode_charging binary into the <code>sbin</code> folder within the ramdisk.
+
Ini akan meng-copy binary file offmode_charging ke folder <code>sbin</code> dalam ramdisk.
  
−
*'''PRODUCT_NAME / PRODUCT_DEVICE''': used for setting the value of your codename. This is the name of the device you load with [[Lunch]].
+
* '''PRODUCT_NAME / PRODUCT_DEVICE''': digunakan untuk men-set codename yang digunakan. Nama device ini yang digunakan dengan perintah [[Lunch]].
  
 
===<code>kernel</code>===
 
===<code>kernel</code>===
  
−
This is simply the prebuilt kernel image or a kernel you built yourself used to boot the device. The format of the kernel may be in a zImage or uImage, depending on the requirements of the architecture of your device.<br />
+
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.
  
 
===<code>cm.mk</code>===
 
===<code>cm.mk</code>===
  
−
You'll need to make a few changes to this file to integrate with the <code>lunch</code>, <code>brunch</code>, and <code>breakfast</code> commands, so that your device shows up on the list and builds properly. You'll also set some variables (see other devices) to indicate what size splash animation should be used, whether this is a tablet or phone, etc.
+
Kita perlu mengubah ke file ini untuk di integrasikan dengan perintah <code>lunch</code>, <code>brunch</code>, dan <code>breakfast</code> , 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.
  
−
Some of these settings aren't used for building just the recovery, but you may as well set them now because once recovery is done and working, the settings here will be important.
+
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.
  
−
Again, take a look at a similar device to yours to get an idea of what the settings here should be. It's fairly intuitive.
+
Sebaiknya, kita lihat lagi device yang mirip dengan device kita untuk memperoleh gambaran settingan mana yang perlu di set. Cara ini mememang memerlukan intuisi.
  
 
===<code>recovery.fstab</code>===
 
===<code>recovery.fstab</code>===
  
−
<code>recovery.fstab</code> defines the file system mount point, file system type, and block device for each of the partitions in your device. It works almost exactly like <code>/etc/fstab</code> in a standard Linux operating system.
+
<code>recovery.fstab</code> mendefinisikan file system mount point, tipe file system, dan block device untuk setiap partisi di device yang kita gunakan. File ini sangat mirip dengan <code>/etc/fstab</code> di sistem operasi Linux.
  
−
Example:
+
Contoh:
  
 
  <code>/system ext4 /dev/block/mmcblk0p32 </code>
 
  <code>/system ext4 /dev/block/mmcblk0p32 </code>
  
−
This sets the block device at <code>mmcblk0p32</code> to be mounted on <code>/system</code> as filesystem type <code>ext4</code>
+
Ini akan menset block device <code>mmcblk0p32</code> untuk di mount di <code>/system</code> dengan tipe filesystem <code>ext4</code>
  
−
All mountpoints should exist in this file and it is '''crucial''' this information be correct or else very bad things can happen, such as a recovery flash writing to the wrong location.
+
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.
  
−
{{note|note=The filesystem type <code>datamedia</code> can be used for internal sdcards as well as setting the block device to <code>/dev/null</code>.}}
+
Tipe filesystem <code>datamedia</code> dapat digunakan untuk sdcard internal juga menset block device ke <code>/dev/null</code>.
  
 
===<code>vendorsetup.sh</code>===
 
===<code>vendorsetup.sh</code>===
  
−
<code>vendorsetup.sh</code> is called when <code>setupenv.sh</code> is run.  It is used to add non-standard <code>lunch</code> combos to the <code>lunch</code> menu.
+
<code>vendorsetup.sh</code> akan di panggil saat <code>setupenv.sh</code> di jalankan.  Ini digunakan untuk menambahkan <code>lunch</code> non-standard yang di kombinasikan ke menu <code>lunch</code>.
  
−
To add your device to the lunch menu:
+
Untuk menambahkan device kita ke menu lunch:
  
 
  <code>add_lunch_combo cm_<codename>-userdebug</code>
 
  <code>add_lunch_combo cm_<codename>-userdebug</code>
  
−
== Then build a test recovery image ==
+
== Build test recovery image ==
 +
 
 +
Untuk build hanya recovery, set <code>lunch</code> sama seperti build biasa, kemudian tulis <code>make recoveryimage</code>
  
−
To build only the recovery, set up <code>lunch</code> as with a regular build, and say <code>make recoveryimage</code>
+
Jika gagal (kemungkinan besar akan gagal), lihat berbagai tip untuk "dealing with build errors" di Wiki CyanogenMod.
  
−
If things break (and they will break), have a look at these tips for [[Doc:_dealing_with_build_errors|dealing with build errors]].
+
Jika kita memiliki [[fastboot]], kita dapat mencoba untuk menginstalasi recovery image ke partisi recovery. Ada ara lain untuk menginstalasi recovery, seperti menggunakan <code>dd</code> dari sistem yang di root untuk mem-flash ke tempat yang di tuju.
  
−
{{tip|tip=If you have [[fastboot]], you can try it to install the recovery image to the recovery partition. There are other methods for installing the recovery, such as using <code>dd</code> from a rooted system to flash it into place.}}
+
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.
  
−
Not much needs to be said here, but make sure the recovery is working before you move on to getting CyanogenMod working.  A 100%-working and reliable recovery mode is absolutely necessary before you start testing experimental Android builds.
 
  
−
=== Adjust <code>recovery_ui.cpp</code> if necessary ===
+
=== Atur  <code>recovery_ui.cpp</code> jika dibutuhkan ===
  
−
You may discover that although the recovery image runs, some of the hardware buttons, such as the volume buttons or power buttons, which would normally be used to scroll through the options, don't work.
+
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.
  
−
You may need to adjust the [[wikipedia:GPIO|GPIO]] values to get the buttons to be recognized. Similarly, you may wish to include/exclude options or modify other UI elements.
+
Kita perlu mengatur nilai [[GPIO]] agar tombol ini dapat di kenali. Sama halnya, jika kita ingin meng-include/exclude opsi atau memodifikasi elemen UI.
  
−
To do this, you may wish to create and edit the <code>/device/[vendor]/[codename]/recovery/recovery_ui.cpp</code>.  You can find ample examples of this file, the associated <code>recovery/Android.mk</code> file that builds it, and how it is used.
+
Untuk itu, kita perlu membuat dan mengedit <code>/device/[vendor]/[codename]/recovery/recovery_ui.cpp</code>.  Kita akan menemukan banyak sekali contoh untuk file ini, maupun file pendamping <code>recovery/Android.mk</code> yang dapat digunakan untuk membuat file tersebut, dan bagaimana cara menggunakannya.
  
−
{{tip|tip=The GPIO values for your device may be found in the kernel source.}}
+
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 ==
  
−
== Put your device folder in github, and use a local manifest to automatically sync it with 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.
  
−
Once you've started your device folder, create your own [http://github.com GitHub] account and [https://help.github.com/articles/creating-a-new-repository set up your folder as a public GitHub repository].  This is a great opportunity to learn about [[git]], and also your source can be accessible to others who can collaborate with you.
+
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'''.
  
−
When naming your repository, use the format '''android_device_VENDOR_CODENAME''', where VENDOR and CODENAME use the new device's values.  So, let's say your GitHub account name is "fat-tire" and your device codename is "[[encore_Info|encore]]", manufactured by Barnes and Noble.  You should call your repository '''android_device_bn_encore'''.  It would be accessible at '''https://github.com/fat-tire/android_device_bn_encore'''.  Similarly, the kernel repository would be called '''android_kernel_bn_encore'''. It would be accessible at '''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:
  
−
The last thing to do is create a [[local manifest]] for other people to use to automatically download and their keep up-to-date with your changes.  Here's an example, using the above scenario:
 
  
 
  <code><?xml version="1.0" encoding="UTF-8"?>
 
  <code><?xml version="1.0" encoding="UTF-8"?>
Line 259: Line 272:
 
  </manifest></code>
 
  </manifest></code>
  
−
{{note|note=The ''revision'' attribute is optional. If it is omitted, <code>repo sync</code> will use the revision specified by the <code><default ... /></code> tag in the [[Doc:_Using_manifests#The_default_manifest|default manifest]].}}
 
  
−
Once you've tested that the [[local manifest]] file works, you can pass it on to others, who can then try out your work.  At that point you can continue to push your changes to GitHub, and even give other users commit access so that you can work on the device together.
+
Catatan: attribut ''revision'' sifatnya opsional. Jika tidak ditulis, maka <code>repo sync</code> akan menggunakan revisi yang tertulis di <code><default ... /></code> 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.
  
−
{{tip|heading=Using other repositories|tip=If you find that for some reason you need to replace or supplement other repositories provided by CyanogenMod, you can add additional repositories using the [[local manifest]]. Once you've got everything working, you can use [[Gerrit]] to submit stuff found in those repositories back upstream to CyanogenMod.}}
+
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.
  
−
== Add the blobs to the <code>vendor/</code> directory ==
+
== Tambahkan blob ke directory <code>vendor/</code> ==
  
−
Once you have a working recovery, it's now time to get CyanogenMod building and working.
+
Setelah kita mempunyai recovery yang berjalan dengan baik, saatnya untuk mem-build CyanogenMod dan jalan.
  
−
The first thing to do is to get all the proprietary, binary blobs into the <code>vendor/</code> folder, along with a <code>.mk</code> file that will include them in the final build.
+
Yang pertama kali perlu dilakukan adalah meletakan semua proprietary binary blob ke folder <code>vendor/</code> bersama file <code>.mk</code> yang akan di tambahkan di build final.
  
−
This requires three steps:
+
Hal ini membutuhkan tiga tahap:
  
−
#Create <code>extract-files.sh</code> and <code>setup-makefiles.sh</code> scripts to pull those blob files from the device using <code>adb</code> and put them in the right <code>/vendor/</code> directory.  There are plenty of examples available for other devices.
+
# Buat script <code>extract-files.sh</code> dan <code>setup-makefiles.sh</code> untuk mengambil blob file dari device menggunakan <code>adb</code> dan meletakannya di directory yang benar di bawah <code>/vendor/</code> .  Ada banyak contoh tersedia untuk berbagai device.
−
#Create an <code>.mk</code> Makefile to copy those files to the <code>$OUT</code> folder during the build process and put them in the right place. Again, use other devices as a guide for what this Makefile should look like. An example filename might be <code>BoardConfigVendor.mk</code>
+
# Buat Makefile <code>.mk</code> untuk mengcopy file ke folder <code>$OUT</code> 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 <code>BoardConfigVendor.mk</code>
−
#Make sure that the Makefile you just created is included from your main <code>BoardConfig.mk</code> via a command such as <code>-include vendor/[vendor]/[codename]/BoardConfigVendor.mk</code>.  Again, existing devices can illustrate how this is done.
+
# Pastikan bahwa Makefile yang kita buat termasuk dalam <code>BoardConfig.mk</code> melalui perintah seperti <code>-include vendor/[vendor]/[codename]/BoardConfigVendor.mk</code>.  Sama seperti sebelumnya, device yang ada harusnya dapat memberikan ilustrasi bagaimana cara membuatnya.
  
−
== Now revise the <code>device/</code> directory ==
+
== Revisi directory  <code>device/</code> ==
  
−
Since you have a working recovery, go back and start modifying the files in the <code>device/</code> folder. As always, use other similar devices as a reference.
+
Karena kita sudah mempunyai directory yang dapat berjalan dengan baik, kembali dan mulai memodifikasi file di folder <code>device/</code> . Seperti biasanya, gunakan device yang mirip sebagai referensi.
  
−
You now have a easy means to do backups and test your builds. So start tweaking the device folder itself, and see if you get it to boot... Once you do, from there its a matter of building and supporting the various parts and peripherals, one-by-one.
+
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.
  
−
== Getting help from the manufacturers & vendors==
+
==Cari pertolongan dari pabrikan & vendor==
  
−
Many of the OEMs (Original Equipment Manufacturers) who make the underlying platform used by your device frequently provide wikis, documentation, and sample code that can assist you in completing your port.  You'll find that some companies are more friendly to the development community than others. Here are some of the more common OEMs and vendors, along with web sites and repositories that may help.
+
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.
  
−
(This list is incomplete.  Please help add to it)
+
(Daftar ini tedak lengkap)
  
 
{| class=wikitable
 
{| class=wikitable
Line 311: Line 325:
 
|}
 
|}
  
−
Sometimes if you have questions you can even reach out to the developers via email or the support forums.
 
  
−
== Adding XML Overlays ==
+
Kadangkala jika kita mempunyai pertanyaan dapat mengirim e-mail ke developer atau support forum.
 +
 
 +
==Menambahkan XML Overlas ==
  
−
It's very likely in your <code>device_[codename].mk</code> file, there's a line that looks like this:
+
Kemungkinan besar di file <code>device_[codename].mk</code> dari device kita, ada kalimat yang kira-kira sebagai berikut:
  
 
  DEVICE_PACKAGE_OVERLAYS := \
 
  DEVICE_PACKAGE_OVERLAYS := \
 
     device/[vendor]/[codename]/overlay
 
     device/[vendor]/[codename]/overlay
  
−
What this does is set the <code>overlay/</code> folder to allow you to override any XML file used by Android frameworks or apps, just for this device. To do so, create a directory structure which mirrors the path leading to an XML file, starting from the root of your source.  Then replace the file you want to overlay.
+
Kalimat ini pada dasarnya menset folder <code>overlay/</code> 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 <code>frameworks/base/core/res/res/values/config.xml</code>.  Copy ke <code>device/[vendor]/[codename]/overlay/frameworks/base/core/res/res/values/config.xml</code>.  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.
  
−
Example:  Let's say you want to override some standard Android settings.  Look at the file in <code>frameworks/base/core/res/res/values/config.xml</code>.  Then copy it to <code>device/[vendor]/[codename]/overlay/frameworks/base/core/res/res/values/config.xml</code>.  Now YOUR version will be used instead of the other one.  You only need to include the settings you wish to override-- not all of them, so you can pare down the file to those few that change from the default.
+
Kita dapat overlay file XML apa saja, yang bereffek pada layout, setting, preferensi, translasi dan lainnya.
  
−
You can overlay any XML file, affecting layouts, settings, preferences, translations, and more.
+
== Membuat kernel dan kernel module dari source code ==
  
−
== Make the kernel and kernel modules build from source ==
+
Jika kita sebelumnya menggunakan pre-built kernel, sampai suatu saat kita ingin mulai membuat kernel dari nol.
  
−
If you have previously used a pre-built kernel, you may at some point want to start building the kernel from scratch.
+
Lihat instruksi cara mengubah file <code>BoardConfig.mk</code> untuk membuat CyanogenMod [[Doc:_integrated_kernel_building|build the kernel and any required kernel modules automatically]].
  
−
See the instructions for how to change the <code>BoardConfig.mk</code> file to make CyanogenMod [[Doc:_integrated_kernel_building|build the kernel and any required kernel modules automatically]].
+
== Penutup ==
 +
 
 +
Memang sulit untuk membahas secara lengkap cara melakukan porting dari awal sampai akhir. AKan tetapi, semoga bagian ini dapat menjelaskan bagaimana berbagai hal di setup dan langkah yang perlu kita ambil. Kita selalu dapat bertanya di forum http://forum.cyanogenmod.org forums atau [[IRC]].
 +
 
 +
Semoga proses yang akan anda lalui akan membawa berkah dan pengetahuan bagi anda, bukan mustahil juga akan memberikan pengakuan :) ..  Ini terutama akan terasa, saat porting kita lakukan dapat bekerja lebih baik daripada stock.
 +
 
 +
Tentunya kita dapat mengkontribusikan pekerjaan kita ke upstream.
 +
[[Doc:_Submitting_A_Port|Here are the instructions]] untuk bagaimana cara melakukannya.
 +
 
 +
Semoga sukses!
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
Cara Porting ROM Android
 +
CROSS-EVERCOSS - Kali ini saya akan mencoba membahas yaitu bagaimana Porting ROM Android, mungkin bagi sebagian orang sangat penasaran bagaiman ya porting ROM?. Dibawah mungkin ada beberapa langkah dalam melakukan porting ROM. Untuk lebih jelas mari simak uraian berikut ini:
 +
PERINGATAN: Harap ikuti tutorial di bawah dengan teliti agar terhindar dari kemungkinan
 +
BRICK, dan ingat saya tidak bertanggung jawab atas segala kerusakan yang mungkin terjadi pada hape anda, jadi lakukan dengan resiko anda sendiri!!!
 +
 
 +
BAHAN BAHAN:
 +
1. Stock Rom
 +
2. Port Rom mt6582 bisa di cari di http://www.needrom.com (usahain spec, ukuran layar sama)
 +
3. Komputer kalau ga punya bisa pakai Root Explorer
 +
4. Notepad++ (untuk komputer)
 +
 
 +
TAHAP AWAL:
 +
1. Untuk komputer Buat 2 folder satu folder di beri nama Stock dan yang satu lagi Port
 +
2. Extract Stock Rom  ke folder Stock dan Port Rom ke folder Port
 +
3. Kalo udah,, ke tahap selanjutnya..
 +
 
 +
TAHAP PORTING:
 +
2.copy file berikut dari stok ke port
 +
 
 +
  1. Folder firmware dan ppp letak nya di system/etc/disini.
 +
  2. File camera.default.so letak nya di system/lib/hw.
 +
  3. File ccci.ko, ccci_plat.ko, ccmni.ko, mtk_stp_wmt.ko, mtk_wmt_wifi.ko, dan pvrsrvkm.ko                  letak nya di system/lib/modules/disini.
 +
  4. File libbluetooth_mtk.so letaknya di system/lib/disini.
 +
  5. File Generic.kl, dan mtk-kpd.kl letaknya di system/usr/keylayout/disini.
 +
  6. File libmnlp letaknya di system/xbin/disini.
 +
  7. Boot.img.
 +
 
 +
3.untuk folder firmware dan ppp hapus dulu dari port,, baru di paste.
 +
4.kalau sudah di pindah semuanya tinggal di zip kan lagi.
 +
kalau makai komputer tandai semua meta if - boot.img - system. lalu pack semua dengan winrar (zip bukan rar), kalau makai Root Explorer tahan lama folder nya  pilih zip this folder.
 +
5. rom portingan siap di instal.
  
−
== 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 [http://forum.cyanogenmod.org 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.  [[Doc:_Submitting_A_Port|Here are the instructions]] for how to do just that.
 
  
−
Good luck!
 
  
 
== See Also ==
 
== See Also ==
Line 348: Line 406:
 
* [https://groups.google.com/forum/?fromgroups#!forum/android-porting Android-Porting] -- the official Google Group on this topic
 
* [https://groups.google.com/forum/?fromgroups#!forum/android-porting Android-Porting] -- the official Google Group on this topic
 
* [http://forum.cyanogenmod.org/topic/15492-general-cyanogenmod-porting-discussion/ General CyanogenMod Porting Discussion] -- a forum post on porting
 
* [http://forum.cyanogenmod.org/topic/15492-general-cyanogenmod-porting-discussion/ General CyanogenMod Porting Discussion] -- a forum post on porting
−
 
  
 
==Referensi==
 
==Referensi==
Line 355: Line 412:
 
* https://groups.google.com/forum/?fromgroups#!forum/android-porting
 
* https://groups.google.com/forum/?fromgroups#!forum/android-porting
 
* http://forum.cyanogenmod.org/topic/15492-general-cyanogenmod-porting-discussion/
 
* http://forum.cyanogenmod.org/topic/15492-general-cyanogenmod-porting-discussion/
 +
* http://wiki.cyanogenmod.org/w/Doc:_integrated_kernel_building
 +
* http://cross-evercoss.blogspot.com/2014/11/cara-porting-rom-android.html
 +
* http://www.needrom.com/download/porting-mtk-rom/
 +
* http://wiki.cyanogenmod.org/w/Build_for_d802

Latest revision as of 09:35, 3 January 2015

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 file (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 GPL 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.

Membuat kernel dan kernel module dari source code

Jika kita sebelumnya menggunakan pre-built kernel, sampai suatu saat kita ingin mulai membuat kernel dari nol.

Lihat instruksi cara mengubah file BoardConfig.mk untuk membuat CyanogenMod build the kernel and any required kernel modules automatically.

Penutup

Memang sulit untuk membahas secara lengkap cara melakukan porting dari awal sampai akhir. AKan tetapi, semoga bagian ini dapat menjelaskan bagaimana berbagai hal di setup dan langkah yang perlu kita ambil. Kita selalu dapat bertanya di forum http://forum.cyanogenmod.org forums atau IRC.

Semoga proses yang akan anda lalui akan membawa berkah dan pengetahuan bagi anda, bukan mustahil juga akan memberikan pengakuan :) .. Ini terutama akan terasa, saat porting kita lakukan dapat bekerja lebih baik daripada stock.

Tentunya kita dapat mengkontribusikan pekerjaan kita ke upstream. 

Here are the instructions untuk bagaimana cara melakukannya.

Semoga sukses! 




Cara Porting ROM Android

CROSS-EVERCOSS - Kali ini saya akan mencoba membahas yaitu bagaimana Porting ROM Android, mungkin bagi sebagian orang sangat penasaran bagaiman ya porting ROM?. Dibawah mungkin ada beberapa langkah dalam melakukan porting ROM. Untuk lebih jelas mari simak uraian berikut ini: PERINGATAN: Harap ikuti tutorial di bawah dengan teliti agar terhindar dari kemungkinan BRICK, dan ingat saya tidak bertanggung jawab atas segala kerusakan yang mungkin terjadi pada hape anda, jadi lakukan dengan resiko anda sendiri!!!

BAHAN BAHAN: 1. Stock Rom 2. Port Rom mt6582 bisa di cari di http://www.needrom.com (usahain spec, ukuran layar sama) 3. Komputer kalau ga punya bisa pakai Root Explorer 4. Notepad++ (untuk komputer)

TAHAP AWAL: 1. Untuk komputer Buat 2 folder satu folder di beri nama Stock dan yang satu lagi Port 2. Extract Stock Rom ke folder Stock dan Port Rom ke folder Port 3. Kalo udah,, ke tahap selanjutnya..

TAHAP PORTING: 

2.copy file berikut dari stok ke port

  1. Folder firmware dan ppp letak nya di system/etc/disini.
  2. File camera.default.so letak nya di system/lib/hw.
  3. File ccci.ko, ccci_plat.ko, ccmni.ko, mtk_stp_wmt.ko, mtk_wmt_wifi.ko, dan pvrsrvkm.ko                  letak nya di system/lib/modules/disini.
  4. File libbluetooth_mtk.so letaknya di system/lib/disini.
  5. File Generic.kl, dan mtk-kpd.kl letaknya di system/usr/keylayout/disini.
  6. File libmnlp letaknya di system/xbin/disini.
  7. Boot.img.

3.untuk folder firmware dan ppp hapus dulu dari port,, baru di paste. 4.kalau sudah di pindah semuanya tinggal di zip kan lagi. kalau makai komputer tandai semua meta if - boot.img - system. lalu pack semua dengan winrar (zip bukan rar), kalau makai Root Explorer tahan lama folder nya pilih zip this folder. 5. rom portingan siap di instal.




See Also

Referensi

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