Presentación

¡Muy buenas a todos!

Esta entrada será la presentación tanto del blog como mía. Como dice en la descripción del blog, vamos a tratar el tema de Compilar Android, pero seguro que os suena más algo sobre compilar CyanogenMod desde sources u otras roms.

Pues bien, nuestro objetivo será recopilar tutoriales e información lo más concreto posible, para así ayudaros mejor y que podáis compilar vuestra propia ROM para vuestro dispositivo. Todavía no soy un experto, y para hacer algunas cosas necesitaréis que algún developer o lo que sea ya ha hecho un trabajo previo. Sin embargo, estoy aprendiendo, y al final, con este blog, podréis compilar vuestra propia CyanogenMod (o lo que prefiráis) desde completamente cero, sin tener nada previo, siendo vosotros los desarrolladores para vuestro dispositivo. 

Es importante que tengáis previos conocimientos sobre manejar Ubuntu y el Terminal, ya que es lo que estaremos usando todo el rato.

Espero que me hayáis entendido, y ya iréis viendo como va la distribución del blog para que todo os sea mucho más fácil.

Y sobre mí, pues tengo experiencia en Android y trabajo en dos dispositivos, el Galaxy Mini 2 y el Galaxy Ace 3, de los cuales tengo sus respectivos blogs especializados y también colaboro en XDA, y creo que eso es lo más importante.

Encontraréis todo lo que necesitáis en las secciones del blog que veis arriba de esta entrada, aunque también podéis buscar a la derecha en los archivos del blog. Comenzad por la sección de "Inicializar Entorno".

Os recomiendo que antes de nada os miréis todas las secciones para que veáis todos los tutoriales que hay.

Dicho esto, empecemos a compilar!

Compilar ROMs en La Nube: Google Cloud Plattform

¡Muy buenas a todos! Hoy os traigo algo que será muy útil para todos aquellos que se vean limitados al compilar, ya sea por una conexión a Internet muy lenta, un ordenador con escasos recursos, poca memoria de almacenamiento, etcétera. Para ello, existen numerosas plataformas en la nube diseñadas para desarrolladores, empresas o simplemente usuarios que la deseen, tales como Amazon, vCloud Air, LabxNow y demás.

Sin embargo, en este tutorial trataremos con Google Cloud Plattform, la cual recomiendo debido a que una vez acabado el periodo de prueba no es muy cara, y porque nos ofrece crear una máquina virtual con realmente mucho potencial tanto en almacenamiento como en CPU y rendimiento.

Una vez dicho esto, empecemos con el tutorial.

Requisitos:

• Una cuenta de Google
• Tarjeta de crédito 
• Ancho de banda algo decente (recomendado)

La tarjeta de crédito es necesaria para registrarnos y activar el periodo de prueba gratuito de 2 meses. Tu tarjeta será cargada con 1$ para la verificación, y luego se te devolverá una vez chequeado todo. Luego, no se te aplicarán cargos durante el periodo de prueba, y cuando este finalice, se te preguntará por si quieres seguir utilizando el servicio y, en caso afirmativo, se realizará el pago correspondiente con tu tarjeta de crédito.

Si tienes todo esto claro, prosigue con el tutorial.

1. Activar Cuenta en Google Cloud

Lo primero de todo será crearnos la cuenta en el servicio y activarla. Para ello, nos dirigiremos a la siguiente dirección: https://cloud.google.com/

Y accederemos a la opción "Pruébalo Gratis":

Como veis, a la derecha de la imagen tenéis explicado lo que os nombré sobre la tarjeta de crédito. Una vez cliques en "Aceptar y continuar", rellenáis la siguiente pantalla con vuestros datos:

Una vez rellenados todos los campos y aceptemos iniciar la versión de prueba, veremos pantallas parecidas a las siguientes. (A partir de ahora las capturas no son mías. Gracias a nitin.chobhe por su publicación en XDA)

Como veis, nos informa de que nos dan 300 créditos para poder gastar durante el periodo de prueba de 2 meses (60 días exactamente). Una vez cliquemos en "GOT IT", habremos completado nuestra cuenta y pasaremos al siguiente paso.

2. Inicializar Entorno de Compilación

En este segundo paso, nos tocará configurar nuestra máquina virtual en la nube para poder compilar. Para ello, seleccionamos el icono de tres barras que ves en la siguiente imagen.

En el menú desplegable, seleccionaremos la opción "Compute Engine".

Y en la página que se mostrará, elegiremos la siguiente opción:

Y se nos mostrará la siguiente pantalla.

Aquí es donde configuramos nuestra máquina virtual. Los campos de "Nombre" y "Zona" los podéis cambiar si queréis, aunque no es algo vital. Luego, recomiendo las opciones que veis en la captura, aunque obviamente podéis cambiarlo para que se adapte mejor a vuestras necesidades.

En el aparte de disco de arranque (Boot disk), seleccionamos la opción de cambiar.

Y entonces elegiremos el tipo de SO (Sistema Operativo) que prefiramos. Personalmente recomiendo Ubuntu 14 ya que es una versión que es de soporte prolongado (Long-Time Support).

Como veis, también podemos modificar el tipo de disco duro que prefiramos, así como la cantidad de memoria que prefiramos. Es por todo ello que al principio dije que recomendaba utilizar Google Cloud, ya que en el menú de antes nos dejaba seleccionar opciones de CPU bastante potentes, y ahora una capacidad de almacenamiento en disco bastante cómoda.

 Así, con los 500GB que veis de ejemplo, podremos alojar unas 2 o 3 ROMs a la vez en dicha máquina, lo cual va bastante bien aunque, como siempre, podéis elegir la configuración que mejor se adapte a cada uno.

Posteriormente, veréis una sección de configuración de Firewall. Recomiendo dejarlo así.

Una vez le des a crear, tardará un minuto o dos en completar la operación. Veremos la siguiente pantalla.

El check verde de abajo nos indica que la máquina está activa. Si clicamos encima, podremos pararla cada vez que queramos. Además, cuando cerremos sesión en el navegador se cerrará automáticamente, así que no os preocupéis por si no la parasteis antes de cerrar el navegador.

Como últimos pasos de este tutorial, clicaremos en la opción "Abrir en ventana del navegador" que vemos remarcada arriba, y veremos la ventana de Terminal conectando.

Y ejecutamos el siguiente comando para obtener permisos root.

                                            sudo -s

Ahora estas listo para empezar a compilar ROMs. No te olvides de configurar el entorno y como siempre, cualquier duda en comentarios. Salu2!!

Compilar Kernel Desde Source

¡Hola amigos! Hoy en este tutorial vamos a aprender algo muy útil en el mundillo de la compilación de Android: vamos a aprender a compilar un kernel desde el código fuente.

Bueno... primero que todo debemos cumplir con unos requisitos los cuales son los siguientes:


Requisitos:

• Sistema operativo basado en linux (recomendado ubuntu)
• Entorno para compilar inicializado
• Mínimo 2GB de RAM disponibles
• Source code de un kernel de nuestro dispositivo
• Toolchain

Una vez hecho esto, podremos comenzar.


1. Preparar Entorno de Trabajo


Primero de todo, procedemos a buscar un source de un kernel para nuestro dispositivo, para ello lo mas fácil es ir a GitHub y poner en la barra de búsqueda el nombre clave de nuestro dispositivo (codename, por ejemplo en mi caso, loganreltexx), para que entiendas mejor esto te invito a visitar una de las entradas del blog en las cuales definimos muchos términos que podrían confundirte.

Una vez lo hayas encontrado, será algo muy parecido a esto:

Luego de hallar un repositorio adecuado vamos a descargarlo como zip y lo descomprimimos en la ruta de nuestra preferencia.

Una vez lo hayamos descargado y situado en una carpeta, pasaremos al siguiente paso.



2. Inicializar Toolchain


En este paso lo que haremos será buscar una toolchain, la cual es la herramienta que usaremos para compilar nuestro kernel. Sabiendo esto les dejare estos link en los cuales podrán bajar varias toolchain para compilar:

• https://github.com/hyper-toolchains/  

Una vez elegida la más adecuada para ti, la descargamos como zip y descomprimimos en ruta de preferencia, como hemos hecho anteriormente con el código fuente del kernel. Con ello, habremos terminado este paso.



3. Compilar Kernel


Sí, ya estamos en el último paso, es un tutorial corto ya que el proceso es relativamente sencillo. Ahora será el momento de abrir el Terminal (Ctrl+T), y vamos a movernos hasta la ruta de trabajo que hayamos elegido.

                                                 cd kernel

*Kernel lo cambias por el nombre que hayas elegido para tu carpeta. Eso sí, recomiendo siempre crearla en el directorio home como hemos hecho siempre*

Una vez situados en la carpeta de trabajo, vamos a ejecutar varios comandos para que el kernel se compile con la toolchain que acabamos de descargar. Por ejemplo, si descomprimí la toolchain en una carpeta llamada "toolchain" en el directorio "home", debería de colocar lo siguiente:

                                     export CROSS_COMPILE=/home/toolchain/bin/arm-eabi-/>

Y a continuación:

                                                   export ARCH=arm<br />


Luego buscaremos en la source del kernel un archivo llamado "defconfig". Este lo podremos encontrar la mayoría de veces en la ruta sourcekernel/arch/arm/configs/codename_defconfig.

Por ejemplo, en mi caso estaría en kernel/arch/arm/configs/loganreltexx_defconfig.

Una vez localizado escribiremos lo siguiente en Terminal:

                                                  make codename_defconfig

Nuevamente reemplazamos "codename" con el de nuestro dispositivo. Por ejemplo, en mi caso sería "make loganreltexx_defconfig"

Como nota, podemos añadir la coletilla "-j#" al final de la línea y, como ya sabemos, la almohadilla la reemplazamos por el número de núcleos de nuestro PC +1.

¡Listo! Ya Has Compilado un Kernel Desde Source

Espero que os haya sido útil esta guía y como siempre, cualquier duda en comentarios.


CRÉDITOS:

• Luis Castillo
• Android Spanish Developers

Portar FIUI v2 desde ROM

¡Buenas a todos! Hoy aprenderemos a portar FIUI, una ROM china que está teniendo mucho auge gracias a su cómoda y vistosa interfaz. Sus creadores la definen como "Future Interactive UI (FIUI)".
Como ya expliqué la diferencia entre portar y compilar en el post para portar MIUI, pues no hace falta que lo vuelva a hacer.

Decir que esta ROM no ha liberado ningún tipo de código fuente, por lo que esta es la única manera de adaptar esta ROM a tu dispositivo. Sin embargo, es bastante sencillo portarla, ya que absolutamente todas las ROMs FIUI están basadas en CM11, aplicando solo ligeros cambios en la interfaz. Por ello, hay un 99% de probabilidades de que consigas un port satisfactorio con mi método.

Dicho esto, comencemos con el tutorial:

*Este tutorial es aplicable a cualquier dispositivo y versión de FIUI*


1. Conceptos Básicos:

Vamos a empezar teniendo claro lo que necesitamos saber y tener para portar esta ROM.


Requisitos: 1. WinRAR 2. Notepad++ 3. Conocimientos básicos


Y antes de nada, hay que tener claros los siguientes conceptos:

Base ROM: La ROM funcional en tu dispositivo. En este caso, SOLO podremos usar CM11 como ROM base.

Port ROM: La ROM que queremos adaptar a nuestro dispositivo. En este caso, será FIUI. Debido a los mínimos cambios que hace a CM11, no importa el dispositivo de dónde extraigas FIUI, aunque recomiendo que sea de uno lo más parecido al tuyo.


Una vez que tengamos esto claro, prosigamos con el tutorial.


2. Preparar Entorno:

Ahora es momento de crear y organizar el directorio donde vamos a trabajar. Para ello, creamos una carpeta llamada "fiui" en la ruta que prefieras. A continuación, creamos dos subcarpetas:

• CM11: Aquí irá la ROM funcional en nuestro dispositivo, que solo podrá ser CM11.
• FIUI: Aquí irá cualquier FIUI de otro dispositivo.

Ahora cogemos cada ROM y extraemos su contenido en su carpeta correspondiente.

Hecho esto, estarás listo para empezar el port.

3. Portando la ROM:

Ahora será el único paso "complicado" del proceso. Básicamente lo que haremos será copiar y pegar archivos y carpetas. Sin embargo, debes prestar mucha atención en cada paso.

---------------------------------------------------------------------------------------------------------

Primero de todo, borramos las siguientes carpetas de CM11:

• system/app
• system/media
• system/priv-app

Y las reemplazamos por las carpetas de FIUI. Es decir, copia esas 3 carpetas desde FIUI a CM11.

---------------------------------------------------------------------------------------------------------

A continuación, dentro de FIUI nos dirigimos a system/etc/permissions y buscamos un archivo llamado com.htc.software.market.xml. Si aparece, lo copiamos en la carpeta system/etc/permissions de CM11. 

Hacemos el mismo proceso con el archivo libAppDataSearch.so, que debe estar localizado en system/lib.

Recuerda: si esos dos archivos no están, no importa. Continúa con el tutorial.

---------------------------------------------------------------------------------------------------------

Ahora copia el archivo "su" desde FIUI hasta CM11. Este archivo se encuentra en la ruta system/xbin, y recuerda, lo pegamos en la misma ruta, pero de CM11.

---------------------------------------------------------------------------------------------------------

En CM11 y FIUI, abrimos el archivo framework-res.apk con WinRAR. Nos desplazamos hasta la carpeta res/xml.

Seguidamente, mueve estos archivos directamente desde el framework-res.apk de CM11 hasta el framework-res.apk de FIUI:

• eri.xml
• storage_list.xml
• apn.xml
• power-profile.xml

Una vez hecho esto, copiamos la carpeta system/framework desde FIUI hasta CM11. Elegimos la opción de combinar carpetas, y reemplazamos cada vez que lo pregunte.

---------------------------------------------------------------------------------------------------------

Por último, abrimos el archivo build.prop de CM11 con Notepad++ y pegamos el siguiente código al final:

                                       #fiui build fiui.ver.name=beta_x.xx. fiui.ver=1 fiui.navbar=0 fiui.traffic=1

Y reemplazamos los valores correspondientes dependiendo de la versión de FIUI que estemos portando.

Una vez hecho, guarda los cambios. Ya has terminado todo el trabajo.


5. Re-empaquetar ROM:

Lo único que falta en ir a la carpeta CM11, seleccionar todas las carpetas y archivos que veamos, y comprimirlas en formato zip.
Una vez finalizado el proceso, ya estará lista para ser instalada en tu dispositivo.

¡Listo! Has Portado FIUI para tu Dispositivo

Compilar AOSPA 4.4 desde Source

Muy buenas a todos! Hoy aprenderemos a compilar AOSPA, también conocida como ParanoidAndroid. Se caracteriza por incluir numerosas funciones exclusivas de personalización, así como ligeras modificaciones en la interfaz.
Para compilarla necesitaréis varias cosas previas que ya haya hecho un desarrollador, ya que incluso yo no sé hacerlas todavía. En cuanto aprenda, lo publicaré y añadiré enlace para redireccionaros a la publicación y luego seguiréis con este tutorial.
Vayamos al lío:


Pre-requisitos:

* Device Tree de CM11 para tu dispositivo (Buscad en GitHub)
* Local_Manifest para tu dispositivo (recomendado)
* Entorno de Compilación Configurado


El device tree es lo más importante. Es lo necesario para que compile con los archivos y características de tu dispositivo para que la ROM sea compatible. Necesitas que algún desarrollador experto lo haga. Yo estoy aprendiendo y en cuanto pueda lo compartiré. El device tree se compone principalmente de tres partes: Device, Kernel y Vendor. Aquí tenéis un ejemplo de device tree (solo device) y como veis son varios archivos y carpetas. Fijaos arriba a la izquierda donde pone "branch" y es una pestaña deslizable. Debéis aseguraros de que vuestro device tree tiene cm-11.0 en esa pestaña.
Dicho esto, prosigamos:


1. Crear Directorio de Trabajo:

El primer paso será crear la carpeta en la que tendremos todo los archivos y en la que se trabajará. La podéis llamar como queráis, pero yo recomiendo llamarla por el nombre de la ROM que vayamos a compilar. Para crear la carpeta hacemos lo siguiente con Terminal:

                                            mkdir aospa
                           

Ahora se habrá creado una carpeta en el directorio Home. La podéis ver si abrís el explorador de archivos. Ahora, vamos a situarnos en esa carpeta con Terminal. Para ello:

                                            cd aospa                                        
Con esto ya habremos creado la carpeta de trabajo y nos habremos situado en ella en Terminal.


2. Descargas las Sources:

En este paso inicializaremos los archivos de código abierto de la ROM que vayamos a compilar, en este caso AOSPA 4.4, y las sincronizaremos a nuestra carpeta de trabajo. Para este paso es necesario el binario repo que ya instalamos al inicializar el entorno de trabajo.
Estando situados en la carpeta "aospa", ejecutamos el siguiente comando:

                          repo init -u https://github.com/AOSPA/manifest -b kitkat

Puede que el terminal os dé algún error y os pida ejecutar algún comando para instalar archivos necesarios. En ese caso, copia lo que te diga el Terminal que ejecutes, y cuando termine vuelve a ejecutar el comando de arriba.

Si todo ha ido bien, se iniciará tu repositorio local usando las sources de AOSPA. Para asegurarse de que se ha descargado, vete a la carpeta "aospa" con el explorador de archivos, y pulsa Ctrl+h y deberá aparecer una carpeta llamada ".repo"

Al finalizar la descarga, Terminal dirá que tienes que registrarte con una cuenta de GitHub. Id a su página oficial y os creáis una cuenta. Una vez creada y comprobada por correo, volver a Terminal y ejecutáis estos dos comandos por separado:

                                  git config --global user.email "tu@correo.com" git config --global user.name "Tu Nombre"  <br>

*Reemplaza "tu@correo.com" y "Tu Nombre" por los que hayas usado al crear la cuenta. Ojo, sin las comillas pero con el espacio después de "user.email" y "user.name" respectivamente*

Una vez registrado recomiendo ejecutar otra vez el comando de descarga de sources y veréis que os aparecerá que estáis identificados al terminar el proceso. Por otro lado, cuando el Terminal os pida si queréis visualización de colores en vuestra cuenta (Enable colour display) escribe una N y le dais a enter.

Hecho esto ya tendremos nuestra carpeta de trabajo lista para obtener las sources de la ROM con la que vamos a trabajar.


3. Sincronizar Repositorio:

Este es el paso más pesado para todo el mundo, ya que descargaremos las sources y pesa entre 10-15GB aproximadamente. Es muy recomendado tener una velocidad de Internet elevada si no quieres morir de aburrimiento. En caso de que quieras aburrirte, ejecuta lo siguiente en Terminal:

*Atención, debemos estar situados en la carpeta aospa. Si has seguido los pasos tal cual sin cerrar el Terminal, estarás situado en ella (lo veréis donde dice ~/aospa~$ al principio de la línea). Si no, sitúate ejecutando "cd && cd aospa".*

                                               repo sync -j#


El # indica el número de trabajos que se usarán para descargar los archivos. Depende de tu velocidad de Internet cuánto ponerle. Yo recomiendo usar de 2 a 4. Por lo tanto, si usas dos el comando quedaría así: repo sync -j2

Tras ejecutar el comando empezará la descarga, y llevará unas cuantas horas, así que podéis ir a tomaros algo o salir a caminar, que es saludable. Cuando termine la sincronización, ya tendremos las sources en nuestra carpeta de trabajo.


4. Configurar Tu Dispositivo:

En este paso es quizá el más complicado ya que no solo será ejecutar comandos en Terminal, sino que tendréis que editar y escribir líneas en varios archivos. Sin embargo, si sigues bien el tutorial te resultará bastante sencillo.

Como dije al principio, es necesario tener localizado el device, kernel y vendor de nuestro dispositivo. En este paso lo que haremos en añadir un archivo a la carpeta de trabajo para que sincronice y descargue las sources específicas de nuestro dispositivo.

Tomaré de ejemplo mi actual dispositivo, el Galaxy Ace 3. Aquí tenéis enlaces de GitHub para que veáis con qué nombre suelen estar:

- Device: https://github.com/kostoulhs/android_device_samsung_loganreltexx
- Kernel: https://github.com/kostoulhs/android_kernel_samsung_loganreltexx
- Vendor: https://github.com/kostoulhs/proprietary_vendor_samsung_loganreltexx


Ahora que tenemos localizados los tres enlaces, vamos a sincronizarlos con nuestra carpeta. Para ello, usaremos el Local Manifest.

Atención: Seguramente si ya hay un desarrollador que ha hecho un Device Tree para CyanogenMod 11, ya haya hecho un local_manifest. Lo encontraréis en su página de GitHub y tendrá un aspecto como éste. En este caso, primero seleccionamos la branch con la que estamos trabajando en la pestaña. La página recargará, entonces clicamos en "local_manifest.xml" y veréis las líneas que tendréis que poner (copiar y pegar) cuando creéis el local manifest.

No me paro a explicar esto de nuevo, ya que lo tenéis explicado en este tutorial específico, además de en tutoriales anteriores sobre ROMs desde source.

Una vez finalizado de escribir el Local Manifest, presiona Ctrol+O y enter para guardar. Luego Ctrl+x para salir del editor. Revisa que el archivo esté en cm11/.repo/local_manifest y que se haya guardado correctamente.

Después de todo esto, ejecuta el comando "repo sync" de nuevo. Tranquilo, no tardará tanto como la primera vez, ya que solo descargará los repo que añadimos en el local manifest.


5. Editar La Source:

En este paso modificaremos y añadiremos diversos archivos a la source, para añadir soporte a nuestro dispositivo. Esto es necesario para cualquier ROM que queramos compilar y que la estemos basando en CyanogenMod. En este tutorial saldrá específicamente para AOSPA. Primero de todo, debemos hacer:

*Atención: todos los archivos y directorios que editaremos/añadiremos están en la ruta del device tree de tu dispositivo*

*Nota: todos los "device" los sustituimos por el "codename" de tu dispositivo, a menos que especifique lo contrario*

Añadir pa.dependencies

Este archivo es igual a "omni.dependencies" que explico en el tutorial de OmniROM. 

Es bastante fácil. Este archivo se basa en el local_manifest. Si has entendido el local_manifest, te resultaŕa fácil hacer este archivo. Varía un poco, ya que aquí la terminología es:

- remote: cuenta de github (CyanogenMod, onmirom, etc)
- repository: enlace del repo quitando "https://github.com/" y el nombre de la cuenta.
- target_path: ruta local del repo. La misma que ponga el local_manifest
- revision: igual que el local_manifest

El ejemplo de estructura que sigue es así:

                    [ { "remote": "kostoulhs", "repository": "android_kernel_samsung_msm8930-common", "target_path": "kernel/samsung/msm8930-common", "revision": "cm-11.0_mod" }, { "remote": "kostoulhs", "repository": "propietary_vendor_samsung_loganreltexx", "target_path": "vendor/samsung/loganreltexx", "revision": "cm-11.0" }, { "remote": "omnirom", "repository": "android_hardware_samsung", "target_path": "hardware/samsung", "revision": "android-4.4" }, { "remote": "omnirom", "repository": "android_device_qcom_common", "target_path": "device/qcom/common", "revision": "android-4.4" }, { "remote": "CyanogenMod", "repository": "android_hardware_qcom_fm", "target_path": "hardware/qcom/fm", "revision": "cm-11.0" }, { "remote": "kostoulhs", "repository": "android_device_samsung_qcom-common", "target_path": "device/samsung/qcom-common", "revision": "cm-11.0" }, { "remote": "kostoulhs", "repository": "android_device_samsung_msm8930-common", "target_path": "device/samsung/msm8930-common", "revision": "cm-11.0" }, { "remote": "kostoulhs", "repository": "android_device_samsung_loganreltexx", "target_path": "device/samsung/loganreltexx", "revision": "cm-11.0" } ]

Por tanto, hay que crear un archivo vacío con el nombre "pa.dependencies". Luego debéis añadir todos los repos de vuestro local manifest siguiendo el formato del ejemplo.

Seguramente, tu device tree venga con el archivo "cm.dependencies". En tal caso, debes borrarlo y crear el archivo desde 0, ya que no viene con la misma estructura.
Al terminar guardamos y cerramos.

Añadir AndroidProducts.mk

Otro archivo que hay que crear en la misma ruta. Seguimos el mismo procedimiento (crear archivo vacío con el nombre AndroidProducts.mk) y lo abrimos con gedit.
A continuación pegamos lo siguiente:

        # # Copyright (C) 2012 The CyanogenMod Project # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/full_device.mk \ $(LOCAL_DIR)/pa_device.mk

Ahora para hacerlo compatible para nuestro dispositivo, haz lo siguiente:

• full_device: lo cambias por el nombre con el que aparezca el archivo "full.mk" en la ruta de tu dispositivo. Por defecto será "full_codename.mk", pero a veces varía.
• pa_device: como dije al principio, debemos cambiar todos los "device" por el codename de nuestro dispositivo.

Guardamos los cambios y cerramos.

Añadir pa_device.mk

Lo que debemos hacer es crear un archivo vacío y lo llamamos "pa_device.mk". Como es evidente, reemplazamos "device" por el nombre de tu dispositivo, como hemos estado haciendo siempre.

Una vez creado, pegamos el siguiente contenido:

    # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Check for target product ifeq (pa_device,$(TARGET_PRODUCT)) # OVERLAY_TARGET adds overlay asset source OVERLAY_TARGET := pa_resolution # Build paprefs from sources PREFS_FROM_SOURCE ?= false # Include ParanoidAndroid common configuration include vendor/pa/main.mk # Inherit AOSP device configuration $(call inherit-product, device/manufacturer/device/full_device.mk) # Override AOSP build properties PRODUCT_NAME := pa_device PRODUCT_BRAND := Manufacturer PRODUCT_MODEL := GT-XXXXX PRODUCT_MANUFACTURER := Manufacturer PRODUCT_BUILD_PROP_OVERRIDES += PRODUCT_NAME=device BUILD_FINGERPRINT="manufacturer/device/codename:4.x.x/XXXXX/XXXXXXXXXX:user/release-keys" PRIVATE_BUILD_DESC="codename-user 4.x.x XXXXX XXXXXXXXXX release-keys" endif

Y para adaptarlo:

• device: Como hemos venido haciendo, se reemplaza por el codename de nuestro dispositivo.
• resolution: Reemplazamos por la resolución del dispositivo (HDPI o XHDPI)
• manufacturer: Se reemplaza por el manufacturador (Samsung, LG, etc)
• BUILD_FINGERPRINT: Lo que debéis escribir entre las comillas que van después de este código, lo tenéis en la línea "ro.build.fingerprint" del build.prop de tu dispositivo.
• PRIVATE_BUILD_DESC: Lo que debéis escribir entre las comillas que van después de este código, lo tenéis en la línea "pro.build.description" del build.prop de tu dispositivo.

Editar vendorsetup.sh

En la misma ruta (aospa/device/manufacturer/codename) abrimos el archivo "vendorsetup.sh" con gedit. Nos aparecerá una línea así:

add_lunch_combo cm_device-userdebug

Simplemente cambia "cm" por "pa". Listo, guarda y sal.



6. Compilar la ROM:

Este es el ansiado paso final con el que crearemos el zip flasheable para nuestro dispositivo. Para ello ejecuta en Terminal:

                                           cd aospa

                                           ./rom-build.sh device

*Como es evidente, también se sustituye "device" como hemos venido haciendo*

Tras ello empezará a compilar y tardará unas horas, todo depende de la potencia que tenga tu PC. Cuando termine, si todo ha ido bien, tendrás el archivo en out/target/product/device.

¡Listo! Ya has compilado AOSPA 4.4

Portar MIUI v6 desde ROM

¡Hola a todos! Hoy trabajaremos también con MIUI, sin embargo, no la vamos a compilar, sino que esta vez la "portaremos". La diferencia entre las dos es bastante sencilla:

• Portar una ROM es adaptar una ya creada para otro dispositivo al nuestro. Por ello, no usaremos "source code" ni nada parecido. 
• Compilar una ROM es construir dicha ROM para tu dispositivo a través del código fuente (source code) oficial del equipo de la ROM que vayamos a trabajar.

Decir que por todo esto, resulta mucho más fácil portar ROMs. Sin embargo, y más en las nuevas versiones Android, no siempre funciona; la mayoría de veces nos quedaremos en la animación de inicio infinitamente.

En mi opinión personal es mucho mejor compilar, ya que es todo más limpio y oficial. Al compilar cogemos archivos de una ROM para otro dispositivo y los adherimos a una ROM del nuestro, así que no queda igual. 

Sin embargo, este proceso es útil si no lograste compilar, justo lo que me pasó a mí con MIUI, que se quedaba con bootloop al compilar con PatchROM, y con este método funcionó bien.

Dicho todo esto, comencemos:

*Este tutorial es aplicable a cualquier versión de MIUI*

*Puedes usar tanto Windows como Linux para este tutorial*


Pre-requisitos:

- MIUI v6 para un dispositivo que tenga un chipset igual al tuyo.
- ROM 4.4.4 funcional en nuestro dispositivo.
- Android Image Kitchen
- Editor de texto avanzado (Recomiendo Notepad++)

*La versión de MIUI  y la ROM funcional en tu dispositivo deben tener la misma versión de Android*

*Ambas ROMs deben ser zip flasheables por custom recovery*

1. Preparar Entorno de Trabajo

Lo primero que haremos será crear y organizar el directorio donde vamos a trabajar. Para ello, creamos una carpeta llamada "miui" en la ruta que prefieras.

Hecho esto, ahora dentro de dicha carpeta crearemos cuatro carpetas más:

- "PORT" (Aquí irá la MIUI a portar)

- "BASE" (Aquí irá la ROM de nuestro dispositivo)

- KitchenPORT (Android Image Kitchen para el boot.img (kernel) de PORT)

- KitchenBASE (Android Image Kitchen para el boot.img de BASE)

Una vez creadas estas carpetas, ya tendremos todo organizado para empezar a portar.

2. Extraer Archivos

En este paso extraeremos los archivos de cada cosa que vayamos a utilizar.

Primero de todo, extraemos el Zip de MIUI en la carpeta PORT. Por lo tanto la estructura de directorio nos quedará algo así:

miui |_PORT |_data |_META-INF |_system |_boot.img

Hacemos lo mismo con la ROM de nuestro dispositivo en BASE. Quedaría algo así:

miui |_BASE |_META-INF |_recovery |_system |_boot.img |_file_contexts

Ahora haremos lo propio con "Android Image Kitchen". Debemos descargarla y extraer su contenido en la carpeta KitchenPORT y KitchenBASE. Ambos directorios quedarán iguales y se verán así:

miui |_KitchenPORT |_android_win_tools |_authors.txt |_cleanup.bat |_repackimg.bat |_unpackimg.bat

miui |_KitchenBASE |_android_win_tools |_authors.txt |_cleanup.bat |_repackimg.bat |_unpackimg.bat

Una vez terminado, ya habremos extraído los archivos que utilizaremos en sus carpetas correspondientes.

3. Intercambiar Archivos

Es el momento del paso final, en el que realmente haremos lo "complicado". Lo que haremos será básicamente intercambiar archivos y carpetas entre la ROM base y la ROM a portar.

Carpetas

Primero de todo, entramos en la carpeta miui/BASE/system y eliminamos las siguientes carpetas:

• app
• fonts
• framework
• media
• priv-app (si existe)

Luego copiamos dichas carpetas que hemos eliminado desde miui/PORT/system. Es decir, copiamos y pegamos esas 5 carpetas desde PORT hasta BASE.


Ahora borramos todo el contenido de la carpeta BASE/system/etc/permissions excepto: 

• platform.xml  
• handheld_core_hardware.xml 

Y como hicimos antes, intercambiamos lo borrado. Es decir, copiamos todo lo que contenga PORT/system/etc/permissions  excepto los dos archivos que no borramos antes y lo pegamos en BASE/system/etc/permissions.


Lo siguiente que haremos es copiar desde PORT/system la carpeta "lib" y la pegamos en BASE/system. Nos preguntará si queremos reemplazar las carpetas, y le decimos que "NO", por lo cual, se combinarán los archivos de ambas carpetas. Repetimos el proceso con las carpetas:

• bin 
• etc 
• xbin

Hecho esto, vamos al directorio PORT/system/lib y copiamos estos tres archivos:

• libandroid_runtime.so
• libandroid_servers.so
• libmedia_jni.so 

Y los pegamos en BASE/system/lib, y ahora "SÍ" los reemplazamos.

Kernel

Ahora trabajaremos con el kernel. Copiamos los boot.img contenidos en PORT y BASE, y los pegamos en KitchenPORT y KitchenBASE respectivamente.


Arrastramos el archivo boot.img sobre el archivo "unpackimg". Se abrirá una ventana de comandos, y nos extraerá el contenido del kernel. Hacemos este proceso con cada kernel en su respectiva carpeta.

Una vez terminado, veremos que ha extraído una carpeta llamada "ramdisk".
Ahora copiamos el archivo KitchenPORT/ramdisk/init.environ.rc a KitchenBASE/ramdisk y le decimos que "SÍ" reemplazamos.

Ahora nos situamos en KitchenBASE, y ejecutamos el archivo "repackimg" (doble click). Una vez terminado el proceso, veremos un nuevo archivo llamado "image-new.img": este será el kernel modificado que usaremos.

Para añadir dicho kernel, lo pegamos en la carpeta BASE (la que contiene la ROM extraída). Borramos el boot.img anterior, y le cambiamos el nombre de image-new.img a boot.img. 

Así, ya tendremos reemplazado el kernel.

Build.prop

Y llegamos paso más sencillo. 

Lo que haremos será abrir el archivo BASE/system/build.prop con Notepad++ y borramos todo lo que aparezca debajo de la siguiente línea (dicha no inclusive):

# # ADDITIONAL_BUILD_PROPERTIES #

Ahora abrimos el "build.prop" de PORT//system/ también con Notepad. Copiamos lo que salga debajo de la línea nombrada anteriormente, y como hemos estado haciendo, intercambiamos. Es decir, pegamos todas las líneas en el "build.prop" de BASE/system.

Updater-Script

Este es el último paso.

Lo que haremos será abrir el archivo BASE/META-INF/com/google/android/updater-script con Notepad.

Abrimos el mismo archivo, pero el del directorio PORT/META-INF/com/google/android/.

Una vez abiertos los dos, intercambiamos líneas. Reemplazamos las líneas que digan lo siguiente:

• Set_perm (también pueden aparecer como set_metadata)
• Symlink

Es decir, quitamos esas líneas del updater-script BASE y pegamos las de PORT. Al terminar guardamos los cambios y cerramos.

Por último seleccionamos todo el contenido de la carpeta BASE y lo comprimimos en un archivo zip

¡Listo! Has Portado MIUI Para Tu Dispositivo

Preparar Stock ROM para Patchrom

En este tutorial aprenderemos cómo preparar las Stock ROMs para compilar MIUI usando patchrom. Es un proceso bastante fácil si usamos una kitchen. El proceso que haremos será:

• Deodexar la ROM
• Añadir root al kernel

Estos dos pasos son fundamentales para que Miui pueda añadir su código a la ROM. Para hacer esto, debemos haber extraído ya el stockrom.zip mediante el comando ADB con Terminal.

Si te da error, o por cualquier otra razón, puedes obtener la Stock ROM por zip flashable siguiendo este tutorial.

Una vez tengamos todo esto, trabajaremos con la cocina.

1. Preparar Entorno

Antes que nada debemos tener instalado el Java Development Kit (JDK). Sin embargo, recomiendo tener todo el entorno de compilación configurado.

Una vez lo tengamos, lo que haremos será configurar la herramienta que utilizaremos para hacer el trabajo, y será dsixda's kitchen. Lo primero que haremos será descargar el paquete necesario desde aquí.

Una vez descargado el paquete comprimido, copiamos la carpeta extraída (kitchen) al directorio "home" (por defecto al abrir el explorador de archivos). Ahora nos situaremos en ella con Terminal:

                                         cd kitchen

Y abrimos su interfaz:

                                         ./menu

Si cumplimos todos los pre-requisitos, debería abrirse sin problemas. Verás lo siguiente:

                =================================================================== Android Kitchen - by dsixda (xda-developers.com) =================================================================== Main Menu 1. Set up working folder from ROM 2. Add root permissions 3. Add BusyBox 4. Disable boot screen sounds 5. Add wireless tethering 6. Zipalign all *.apk files to optimize RAM usage 7. Change wipe status of ROM 8. Change name of ROM 9. Check update-script for errors 10. Show working folder information Advanced Options 11 - Deodex files in your ROM 12 - Add task killer tweak for speed (stock ROM only) 13 - Add /data/app functionality 14 - Add Nano text editor + sysro/sysrw 15 - Add Bash (command shell) 16 - Add Apps2SD 17 - Add /etc/init.d scripts support (busybox run-parts) 18 - Add custom boot animation functionality 19 - Porting tools (experimental) 20 - Tools for boot image (unpack/re-pack/etc.) 21 - Unpack data.img 22 - Sign APK or ZIP file(s) 23 - Convert update-script or updater-script 24 - Miscellaneous optins / Plugin scripts 99. Build ROM from working folder 00. About/Update kitchen 0. Exit

Hecho esto ya habremos configurado la cocina.


2. Añadir Soporte a tu Dispositivo

Lo que haremos ahora será añadir soporte a tu dispositivo para la cocina. No es algo estrictamente vital para lo que vamos a hacer ya que podemos editar los mount points luego, pero recomiendo hacerlo y así ya lo tienes con soporte para todas las veces que la uses.

La lista oficial de dispositivos soportados es la siguiente:

    --------------------------------------------------- MediaTek MT65xx-based devices - Discussion thread here - MT657X devices: See this post for details - MT6589 devices: See this post - IMPORTANT: You may need to define your device under the kitchen's /tools/edify_defs folder, or it might not boot! Read the instructions in FAQ section: 'How to Add New Devices' --------------------------------------------------- Alphabetical list of rest of devices: Acer Liquid Dell Streak 7 HTC Amaze 4G HTC Aria / Liberty HTC Desire HTC Desire HD / Inspire 4G HTC Desire S HTC Desire Z / Vision / T-Mobile G2 HTC Dream / G1 HTC Droid DNA HTC Droid Eris HTC Evo 3D HTC Evo 4G HTC Evo 4G LTE HTC Evo View 4G (untested) HTC Evo Shift 4G HTC Flyer (untested) HTC HD2 - Use NAND ROM method (Please follow this thread for details) HTC Hero / G2 Touch HTC Incredible HTC Incredible 2 HTC Incredible S HTC Legend HTC Magic / myTouch 3G HTC myTouch 3G Slide HTC myTouch 4G / Glacier HTC Nexus One HTC One (m7 variant) HTC One S HTC One X HTC One X+ (AT&T and International versions) HTC One XL HTC One V (including CDMA version) HTC Rezound HTC Sensation HTC Tattoo / Click HTC Thunderbolt HTC Wildfire / Buzz HTC Wildfire S Huawei - Newer devices (2013+): - Custom ROMs *not* supported, but to extract files from firmware, please follow this thread. Huawei Ideos X6 - Please follow this thread for details Huawei U8100/U8110/U8120/U8150/U8160/U8180/U8650 Huawei U8220 / T-Mobile Pulse LG Ally LG GT540 Optimus LG Motion 4G - Please follow this thread for details LG Nexus 4 (mako) LG Optimus 2X (P990) LG Optimus Black - Please follow this thread for details LG Optimus G2X (P999) LG P500 - Please follow this thread for details LG Shine Plus LG Vortex Micromax A60 Motorola Atrix (unconfirmed) Motorola CLIQ / CLIQ XT Motorola Droid Motorola Droid Bionic - Please follow this thread for details Motorola Milestone (unconfirmed) - You may need to remove the boot.img before building Prestigio MultiPhone 4500 DUO Prestigio MultiPhone PAP4500TDUO Samsung Galaxy Ace 2 - GT-I8160(L/P) Samsung Galaxy Mini Samsung Galaxy Nexus (untested, 'maguro' and 'toro' versions only) Samsung Galaxy Note - GT-N7000 - please follow this thread for details - SGH-I717 - Please follow this thread for details Samsung Galaxy Note 2 - Supported for: -- Sprint variants - SPH-L900 - Please follow this guide -- T-Mobile variants - SGH-T889(V) - Please follow this guide -- Verizon variants - SCH-I605 (unconfirmed - see this equivalent guide) -- International variants - GT-N7100/N7105(T)/N7108 (unconfirmed - see this equivalent guide) -- AT&T/Rogers/Bell/Telus variants - SGH-I317(M) (unconfirmed - see this equivalent guide) -- US Cellular variants - SCH-R950 (unconfirmed - see this equivalent guide) Samsung Galaxy R GT-I9103 Samsung Galaxy S (GT-I9000 and most variants) - Please follow this thread for details Samsung Galaxy S Plus (GT-I9001) - Please follow this thread for details Samsung Galaxy S2 - Supported for: -- GT-I9100 and Exynos CPU variants - Please follow this thread for details -- Qualcomm/LTE variants (AT&T Skyrocket, Rogers, Telus, T-Mobile, Bell HD LTE SGH-I757M, Telstra GT-I9210T) - Please follow this thread for details Samsung Galaxy S3 - Supported for: -- T-Mobile/Mobilicity/Wind variants: SGH-T999(V) - Click here for a guide -- AT&T/Rogers/Bell/Telus variants: SGH-I747(M) - Click here for a guide -- Verizon variants: SCH-I535, SCH-R530U - Click here for a guide -- Sprint variants: SPH-L710, SCH-L710 - Click here for a guide -- International variants: GT-I9300(T) - Click here for a guide -- International LTE variants: GT-I9305(T) - Click here for a guide -- Korean variants: SHV-E210K/L/S and SHW-M440S (unconfirmed) Samsung Galaxy S4 - NOTE: Kitchen only supports creating ROMs from stock firmware or importing ROMs made only with kitchen! - Supported for: -- AT&T variant (SGH-I337) -- Bell/Telus/Rogers variant (SGH-I337M) -- T-Mobile variant (SGH-M919) -- Wind/Mobilicity variants (SGH-M919V) - untested -- International non-LTE variant (GT-I9500) - untested -- International LTE variant (GT-I9505) - untested -- Other American variants (SCH-R970, SPH-L720, SCH-I545) - untested Samsung Galaxy W (GT-I8150) - Please follow this thread for details Samsung Nexus S / Nexus S 4G Sony Ericsson Xperia 2010 devices (X10 / X10 Mini / X10 Mini Pro) - Can only build ROM without boot.img (please follow this thread for details) Sony Xperia 2011-12 devices, specifically: - TX, P, U, Sola - Active, Arc, Arc S, Mini, Mini Pro, Neo, Neo V, Neo L, Play, Ray (follow steps below): - Can only build ROM without boot.img - If using stock FTF for kitchen: 1) Unzip FTF file, extract the system.sin 2) Dump system image from system.sin w/ Flashtool (Advanced-> SIN Editor) 3) Rename dumped file to system.img - OR If using Nandroid backups: Rename system.yaffs2.img to system.img - Use this system.img in kitchen's original_update folder - WARNING - If using a ROM made from system.sin (not Nandroid), it is recommended to flash from the temporary (fastboot) Clockwork Recovery, rather than the regular Clockwork Recovery, otherwise device may not boot (possibly because custom recovery files in system folder are not added to ROM? e.g. recovery.tar). ZTE Blade / Orange San Francisco

Si tu dispositivo no se encuentra en esa lista, habrá que hacer lo siguiente:

Nos dirijimos a la carpeta kitchen/tools/edify_defs y creamos un archivo vacío que lleve de nombre el "codename" de nuestro dispositivo. (El codename lo puedes ver en la línea ro.product.device del build.prop de tu dispositivo)
Una vez creado, tendremos que obtener los mount points de nuestro dispositivo. Para ello habrá que desempaquetar el "recovery.img" de tu dispositivo, y abrir el archivo "recovery.fstab" que estará en la carpeta ramdisk. Puedes hacer ese proceso de desempaquetado con la misma dsxida's kitchen o con este tutorial.

Cuando tengamos localizados los puntos de montaje, abriremos el archivo vacío que creamos y habrá que especificarle a la cocina en ese archivo cuáles son los mount points de nuestro dispositivo. Para ello abre otro archivo de tools/edify_defs de un dispositivo del mismo manufacturador que el tuyo y sigue el mismo esquema en tu archivo. Una vez hecho, guarda los cambios y cierra.

Con esto ya habrás dado soporte a la cocina. Sigamos:


4. Modificar la Stock ROM

Una vez hayamos configurado correctamente la cocina, editaremos el zip de la Stock ROM. Para ello, lo primero que haremos será copiar el archivo comprimido de la ROM en la carpeta "/kitchen/original_update".

Una vez copiado, iremos al Terminal con la cocina abierta, y teclearemos el número 1 (Set up working folder from ROM) y le damos a enter. Esto inicializará la carpeta dónde trabajará la cocina.

Ahora realizaremos las dos modificaciones necesarias.

Deodexar ROM

Para deodexar la ROM (quitar archivos .odex) debemos seleccionar la opción número 11 de la cocina, y le damos a enter. Al finalizar el proceso ya habremos hecho este vital paso para Miui.

Añadir Kernel Root

Para añadir el root al kernel, ejecutaremos la opción número 2 para añadir acceso root, y seguidamente tecleamos "s" y le damos a enter de nuevo. Cuando termine le damos a enter y la cocina volverá al menú principal.

Hecho esto ya tendremos lista la ROM. Ahora, para convertirla a formato zip,  teclea la opción 99 (Build ROM from working folder) y cuando te diga que tipo de guía durante la instalación, elige la interactiva.

La interfaz te irá guiando durante el proceso, y lee con atención todo lo que te vaya preguntando, pero no deberá haber ningún tipo de problema.
Al terminar encontrarás el archivo en la carpeta "OUTPUT_ZIP" dentro de "/kitchen". Lo siguiente será llamarlo "stockrom.zip" y reemplazarlo por el antiguo zip de la carpeta "patchrom/codename".

*Si se ha creado en patchrom/codename una carpeta "stockrom", deberás reemplazar el boot.img por el que tiene la ROM obtenida de la cocina, así como la carpeta "system".

¡Listo! Sigue Compilando Miui

Solucionar Rejects en MIUI (Failed Hunks)

¡Muy buenas a todos! Hoy estoy muy emocionado ya que he conseguido aprender y solucionar los rejects que impiden compilar MIUI usando patchrom. Me siento orgulloso de hacer un gran post explicándolo todo detalladamente, ya que por Internet no hay casi información.

Os explicaré teoría y el proceso para parchear manualmente, así aprendemos más todos ;-)
Dicho esto, empecemos:

-------------------------------------------------------------------------------------------------------

Una vez llegado el momento de usar la herramienta de parchear los framework para añadirle el código de MIUI (make firstpatch) saldrán en Terminal un montón de líneas que dirán: HUNK SUCCEEDED. 

Eso significa que se ha aplicado el parche correctamente. Sin embargo, en numerosas ocasiones veremos líneas que dirán lo siguiente:

                       Hunk #1 FAILED at 111. 1 out of 1 hunks FAILED -- saving rejects to file android.services.jar.out/PhoneWindowManager.smali.rej

Eso significa que no se ha podido aplicar el parche, y se ha guardado el registro del error en un archivo ".smali.rej" en la carpeta patchrom/codename/temp/reject.

Decir que MIUI decompila los apk y los archivos jar del framework de nuestro dispositivo para añadirle su código. Esto lo hace usando el lenguaje "smali", que así resumido está "antes" que el formato JAVA. No hay mucha información sobre ello, aunque no es relevante para saber solucionar los rejects. Si quieres tienes más información aquí.

Pues una vez haya terminado el proceso "make firstpatch" lo primero que tendremos que hacer es dirigirnos a la carpeta "reject". Dentro de ella, encontraremos las siguientes carpetas:

• android.policy.jar.out
• services.jar.out  
• framework.jar.out
• framework2.jar.out
• telephony-common.jar.out

Estos son los nombres de los archivos decompilados de nuestro  dispositivo (lógicamente solo es un nombre de carpeta añadiendo la terminación .out). 

Entonces abrimos por ejemplo "android.policy.jar.out" y seguimos abriendo todas las carpetas que son aparezcan hasta encontrar un archivo ".smali.rej"

Una vez encontrado, buscaremos el archivo base. Este se encontrará en la carpeta raíz de tu dispositivo. En este caso, estará en "patchrom/codename/android.policy.jar.out/smali/" y luego seguirá la misma ruta que el reject.

Es decir, si el reject está en:

patchrom/codename/temp/reject/android.policy.jar.out/smali/com/android/internal/policy/impl

Entonces el archivo a editar estará en:

patchrom/codename/android.policy.jar.out/smali/com/android/internal/policy/impl

Los dos archivos deben llamarse exactamente igual, exceptuando que el reject tendrá la extensión ".rej" añadida.

Una vez ubicado el reject y el archivo base, abriremos los dos con Gedit (o el editor de texto que prefieras).
Nos fijamos en el reject; nos encontraremos con algo así:

    *** PhoneWindowManager.smali 2015-09-09 11:46:13.541852561 -0300 --- PhoneWindowManager.smali 2015-09-09 11:47:07.349851413 -0300 *************** *** 393,404 **** .field private mPowerKeyTriggered:Z ! .field private final mPowerLongPress:Ljava/lang/Runnable; .field mPowerManager:Landroid/os/PowerManager; .field mPreloadedRecentApps:Z .field mRecentAppsDialog:Lcom/android/internal/policy/impl/RecentApplicationsDialog; .field mRecentAppsDialogHeldModifiers:I --- 395,408 ---- .field private mPowerKeyTriggered:Z ! .field private mPowerLongPress:Ljava/lang/Runnable; .field mPowerManager:Landroid/os/PowerManager; .field mPreloadedRecentApps:Z + .field private final mQuickBootLock:Ljava/lang/Object; + .field mRecentAppsDialog:Lcom/android/internal/policy/impl/RecentApplicationsDialog; .field mRecentAppsDialogHeldModifiers:I


Explico la terminología:

• *** XX,XX*** : esto indica las líneas dónde el parche esperaba que se encontraran las líneas que aparecen debajo. Es decir, que deberían haber estado entre la línea XX y la XX.
• --- XX,XX--- : esto indica las líneas dónde quedarían las líneas una vez aplicado el parche.

Sin embargo, nos olvidamos de las líneas dónde deberían estar o no, y nos centramos en lo siguiente:

• Lo que aparece debajo de los asteriscos es cómo aparecen antes de parchear.
• Lo que aparece debajo de los guiones es cómo aparecerán una vez aplicado el parche.

Y claro, nosotros estamos aquí porque no se pudo aplicar el parche, por lo que debemos aplicarlo nosotros manualmente.

Para ello, hay que saber la simbología:

• + significa que esa línea ha sido añadida por el parche.
• - significa que esa línea ha sido eliminada por el parche.  
• ! significa que esa línea ha sido modificada por el parche.

Sabido esto, vamos a arreglar ese reject...Voy a solucionar el reject del ejemplo, luego tú harás lo correspondiente al  tuyo. Primero de todo, nos fijamos en el source input (asteriscos):

*** 393,404 **** .field private mPowerKeyTriggered:Z ! .field private final mPowerLongPress:Ljava/lang/Runnable; .field mPowerManager:Landroid/os/PowerManager; .field mPreloadedRecentApps:Z .field mRecentAppsDialog:Lcom/android/internal/policy/impl/RecentApplicationsDialog; .field mRecentAppsDialogHeldModifiers:I

Con esto sabemos que así es como aparecen esas líneas en el archivo base. Entonces nos dirigimos al archivo base y buscamos esas líneas. Estarán unas 200 líneas arriba o abajo de como indica el reject. En este caso, estarán cerca de la línea 400 y pico.

*Atención: las líneas pueden aparecer con algunos valores diferentes a los que dice el source input del reject, es normal. También pueden aparecer en distinto orden, etc.*

Una vez encontradas las líneas, veremos lo siguiente

          .field private mPowerKeyTriggered:Z .field private final mPowerLongPress:Ljava/lang/Runnable; .field mPowerManager:Landroid/os/PowerManager; .field mPreloadedRecentApps:Z .field private mPressOnAppSwitchBehavior:I .field private mPressOnAssistBehavior:I .field private mPressOnMenuBehavior:I .field private final mQuickBootLock:Ljava/lang/Object; .field private final mQuickBootPowerLongPress:Ljava/lang/Runnable;

Como veis, algunas están en otro orden y otras directamente no están. Entonces nos fijamos ahora en el "after patch" (guiones):


--- 395,408 ---- .field private mPowerKeyTriggered:Z ! .field private mPowerLongPress:Ljava/lang/Runnable; .field mPowerManager:Landroid/os/PowerManager; .field mPreloadedRecentApps:Z + .field private final mQuickBootLock:Ljava/lang/Object; + .field mRecentAppsDialog:Lcom/android/internal/policy/impl/RecentApplicationsDialog; .field mRecentAppsDialogHeldModifiers:I


Entonces sabemos que:

•  La línea ".field private  final mPowerLongPress:Ljava/lang/Runnable;" que aparece en el source input es editada. Lo sabemos porque lleva la exclamación (!) delante. Al mirar el "after patch" vemos que tendrá que verse así: ".field private mPowerLongPress:Ljava/lang/Runnable;".
• Vemos que en el "after patch" se indica que hay que agregar la línea ".field private final mQuickBootLock:Ljava/lang/Object;" ya que tiene delante el signo más (+).

Entonces lo que haríamos sería editar una línea como indica el "after patch" y agregar otra. Las adiciones (+) se copian tal cual están en el reject.

Sin embargo hay que tener en cuenta una cosa, y es que los archivos están parcialmente parcheados. Por ello, no tendrás que hacer todo lo que el reject dice. Por ejemplo, si te fijas, la adición que el reject indica que tengo que hacer ya está aplicada en el archivo base.
Entonces debes fijarte siempre y asegurarte de que la línea ya está añadida/removida.

Entonces, para solucionar este reject solo tendré que editar una línea. Una vez hecho, la parte a editar del archivo base quedará así:

            .field private mPowerKeyTriggered:Z .field private mPowerLongPress:Ljava/lang/Runnable; .field mPowerManager:Landroid/os/PowerManager; .field mPreloadedRecentApps:Z .field private mPressOnAppSwitchBehavior:I .field private mPressOnAssistBehavior:I .field private mPressOnMenuBehavior:I .field private final mQuickBootLock:Ljava/lang/Object; .field private final mQuickBootPowerLongPress:Ljava/lang/Runnable;

Y ahora solo tocará guardar los cambios, salir, y pasar al siguiente reject para seguir aplicando parches y parches.

Decir que en un reject encontrarás más de una caja de modificación. Con caja de modificación me refiero al conjunto del "source input" y el "after patch". Es decir, te podrás encontrar esto:

*** PhoneWindowManager.smali 2015-09-09 11:46:13.541852561 -0300 --- PhoneWindowManager.smali 2015-09-09 11:47:07.349851413 -0300 *************** *** 393,404 **** .field private mPowerKeyTriggered:Z ! .field private final mPowerLongPress:Ljava/lang/Runnable; .field mPowerManager:Landroid/os/PowerManager; .field mPreloadedRecentApps:Z .field mRecentAppsDialog:Lcom/android/internal/policy/impl/RecentApplicationsDialog; .field mRecentAppsDialogHeldModifiers:I --- 395,408 ---- .field private mPowerKeyTriggered:Z ! .field private mPowerLongPress:Ljava/lang/Runnable; .field mPowerManager:Landroid/os/PowerManager; .field mPreloadedRecentApps:Z + .field private final mQuickBootLock:Ljava/lang/Object; + .field mRecentAppsDialog:Lcom/android/internal/policy/impl/RecentApplicationsDialog; .field mRecentAppsDialogHeldModifiers:I *************** *** 11952,11957 **** if-eqz v12, :cond_19 invoke-interface {v11}, Lcom/android/internal/telephony/ITelephony;->endCall()Z :try_end_5 .catch Landroid/os/RemoteException; {:try_start_5 .. :try_end_5} :catch_2 --- 12006,12013 ---- if-eqz v12, :cond_19 + if-eqz p3, :cond_19 + invoke-interface {v11}, Lcom/android/internal/telephony/ITelephony;->endCall()Z :try_end_5 .catch Landroid/os/RemoteException; {:try_start_5 .. :try_end_5} :catch_2


Entonces haríamos cada uno por separado. El primero ya lo hice yo, entonces pasaríamos al segundo:

*** 11952,11957 **** if-eqz v12, :cond_19 invoke-interface {v11}, Lcom/android/internal/telephony/ITelephony;->endCall()Z :try_end_5 .catch Landroid/os/RemoteException; {:try_start_5 .. :try_end_5} :catch_2 --- 12006,12013 ---- if-eqz v12, :cond_19 + if-eqz p3, :cond_19 + invoke-interface {v11}, Lcom/android/internal/telephony/ITelephony;->endCall()Z :try_end_5 .catch Landroid/os/RemoteException; {:try_start_5 .. :try_end_5} :catch_2

Pero ya te tocará hacerlo a ti ;-) Hasta aquí el tutorial sobre solucionar los rejects. Suerte a todos y cualquier pregunta en comentarios.

¡Listo! Has Aprendido a Solucionar Rejects

Compilar TWRP desde Source

Muy buenas a todos! Hoy no aprenderemos a compilar una ROM, sino un custom recovery: TeamWinRecoveryProject. Es vital tener un recovery alternativo para poder instalar ROMs, Tweaks, etc. Para mí este recovery es mucho mejor que CWM, sin embargo, para compilarlo hace falta tener un Device Tree para nuestro dispositivo.
Empecemos:


Pre-requisitos:

* Device Tree de CM (>10.0) para tu dispositivo (Buscad en GitHub)
* Local_Manifest para tu dispositivo (recomendado)
* Entorno de Compilación Configurado


Se recomienda usar el Device Tree de OmniROM para tu dispositivo ya que vendrá con el código de TWRP añadido. Sin embargo, también se puede usar CyanogenMod 10.0-11 (y 12 con un parche).
Puedes usar las sources de OmniROM sin tener compilada OmniROM para tu dispositivo, sin embargo, deberás hacer unos cambios extras. Por ello, usaré como ejemplo las sources de CyanogenMod en este tutorial.

El único paso que te ahorras usando OmniROM es el de reemplazar una carpeta, así que poca cosa.
Por ello, recomiendo usar las sources de la ROM que tengas para tu dispositivo, y sincronizar con la misma branch. Es decir, haremos todo como si fueras a compilar una ROM.

Entonces queda claro que necesitas tener CyanogenMod funcionando en tu dispositivo y tener las sources ubicadas. Dicho esto empecemos con el tutorial:

1. Crear Directorio de Trabajo

El primer paso será crear la carpeta en la que tendremos todo los archivos y en la que se trabajará. La podéis llamar como queráis, pero yo recomiendo llamarla por el nombre de lo que vayamos a compilar. Para crear la carpeta hacemos lo siguiente con Terminal:

                                              mkdir twrp

Ahora se habrá creado una carpeta en el directorio Home. La podéis ver si abrís el explorador de archivos. Ahora, vamos a situarnos en esa carpeta con Terminal. Para ello:

                                             cd twrp

Con esto ya habremos creado la carpeta de trabajo y nos habremos situado en ella en Terminal.


2. Descargar las Sources

En este paso inicializaremos los archivos de código abierto de lo que vayamos a compilar. En este tutorial usaré como ejemplo las sources CyanogenMod 11 (si tu dispositivo tiene solo CM12 u otra, pues sincroniza con la branch correspondiente), y sincronizaremos a nuestra carpeta de trabajo. Para este paso es necesario el binario repo que ya instalamos al inicializar el entorno de trabajo.
Estando situados en la carpeta "twrp", ejecutamos el siguiente comando:

                  repo init -u git://github.com/CyanogenMod/android.git -b cm-11.0

Puede que el terminal os dé algún error y os pida ejecutar algún comando para instalar archivos necesarios. En ese caso, copia lo que te diga el Terminal que ejecutes, y cuando termine vuelve a ejecutar el comando de arriba.
Si todo ha ido bien, se iniciará tu repositorio local usando las sources de CM11. Para asegurarse de que se ha descargado, vete a la carpeta omni con el explorador de archivos, y pulsa Ctrl+h y deberá aparecer una carpeta llamada ".repo"
Al finalizar la descarga, Terminal dirá que tienes que registrarte con una cuenta de GitHub. Id a su página oficial y os creáis una cuenta. Una vez creada y comprobada por correo, volver a Terminal y ejecutáis estos dos comandos por separado:

                          git config --global user.email "tu@correo.com" git config --global user.name "Tu Nombre"
 *Reemplaza "tu@correo.com" y "Tu Nombre" por los que hayas usado al crear la cuenta. Ojo, sin las comillas pero con el espacio después de "user.email" y "user.name" respectivamente*

Una vez registrado recomiendo ejecutar otra vez el comando de descarga de sources y veréis que os aparecerá que estáis identificados al terminar el proceso. Por otro lado, cuando el Terminal os pida si queréis visualización de colores en vuestra cuenta (Enable colour display) escribe una N y le dais a enter.

Hecho esto ya tendremos nuestra carpeta de trabajo lista para obtener las sources.


3. Sincronizar Repositorio:

Este es el paso más pesado para todo el mundo, ya que descargaremos las sources y pesa entre 10-15GB aproximadamente. Es muy recomendado tener una velocidad de Internet elevada si no quieres morir de aburrimiento. En caso de que quieras aburrirte, ejecuta lo siguiente en Terminal:

*Atención, debemos estar situados en la carpeta twrp. Si has seguido los pasos tal cual sin cerrar el Terminal, estarás situado en ella (lo veréis donde dice ~/twrp~$ al principio de la línea). Si no, sitúate ejecutando "cd && cd twrp".*

                                         repo sync -j#
El # indica el número de trabajos que se usarán para descargar los archivos. Depende de tu velocidad de Internet cuánto ponerle. Yo recomiendo usar de 2 a 4. Por lo tanto, si usas dos el comando quedaría así: repo sync -j2

Tras ejecutar el comando empezará la descarga, y llevará unas cuantas horas, así que podéis ir a tomaros algo o salir a caminar, que es saludable. Cuando termine la sincronización, ya tendremos las sources en nuestra carpeta de trabajo.


4. Descargar Device Tree

Ahora descargaremos las sources de nuestro dispositivo mediante el uso del local manifest. Si ya tienes CyanogenMod en tu dispositivo, seguramente el desarrollador haya publicado el local manifest.

*Un truco para ver los repos que usó el desarrollador si no ha publicado el local manifest, es abrir el archivo "cm.dependencies" del device tree*

Si no, hazlo tú mismo. No voy a ponerme a explicarlo de nuevo ya que lo tienes explicado aquí, y en los tutoriales de compilar CynaogenMod y OmniROM la información de dónde se coloca.

Decir que para compilar TWRP no necesitaremos repositorios como el Hardware FM y demás, pero recomiendo sincronizar todos los que tenga el local_manifest.

Una vez colocado el local manifest, sincronizaremos usando el comando "repo sync" de nuevo.

Hasta aquí es todo el proceso como si fuéramos a compilar CyanogenMod.

5. Añadir Código TWRP

Hasta ahora todo había sido muy fácil. Pero ahora llega lo complicado. Hay que editar archivos, pero es difícil saber qué añadir.

Bootable Recovery

Este es un paso necesario si estamos usando las sources de CyanogenMod. Lo que debemos hacer es ir a esta página. Seleccionamos la branch más actualizada.

*Da igual que sea 5.1 si nuestro dispositivo es 4.4 o lo que sea. Elegimos la última ya que con ella viene la última versión de TWRP*

Entonces vamos a la izquierda de la página de le damos a "download zip". Una vez descargado, lo descomprimimos pegamos en la carpeta twrp/bootable/recovery (ojo, borra todo lo que contenga esa carpeta antes de pegar lo descargado).

Una vez pegado ya habremos reemplazado las sources de recovery de CM por las de OmniROM, que traen el código de TWRP. Si usamos las sources de OmniROM, no hace falta este paso.

Recovery.te

Este paso solo será necesario si estamos usando las sources de CyanogenMod 12. Aplicaremos un parche. 

Para ello habrá que ir a la ruta twrp/external/sepolicy y abrimos con Gedit un archivo llamado "recovery.te".

Buscamos la línea que diga "recovery_only(`" y justo debajo escribimos lo siguiente:

                                         permissive recovery;

*Atención: hay que dejar dos espacios de margen. Que coincida con el principio de la siguiente línea. Quedaría así (el ejemplo de la derecha)*

Adaptar Source OmniROM

Este paso solo es necesario si usas las sources de OmniROM y tu dispositivo no tiene dicha ROM compilada, es decir, estás usando el device tree de CyanogenMod para tu dispositivo.

Para hacerlo, sigue el paso 5 del tutorial para compilar OmniROM

Si lo haces, recomiendo que al acabar de compilar TWRP, hagas también OmniROM para tu dispositivo, ya que lo tendrás todo listo para ello ;-)

Device.mk

Ahora haremos una ligera modificación en el archivo device.mk. Está en la ruta twrp/device/marca/codename y aparece con el nombre "codename.mk". Mi dispositivo se llama "loganreltexx", por lo que el archivo me saldrá como "loganreltexx.mk".

Abrimos el archivo y escribimos lo siguiente:

                          PRODUCT_COPY_FILES += \ $(LOCAL_PATH)/recovery/twrp.fstab:recovery/root/etc/twrp.fstab

Esto hará que se copie el archivo twrp.fstab que crearemos más adelante en este tutorial en la ruta /etc al iniciar en modo TWRP.

Editar BoardConfig.mk

Esta parte es la más complicada. Primero de todo vete a twrp/device/marca/codename y abre el archivo BoardConfig.mk con Gedit.
Busca una línea (Ctrl+f) llamada TARGET_RECOVERY_INITRC. Si aparece, después del igual (=) estará escrita una ruta a un archivo "init.recovery.rc". Id a esa ruta (suele estar en rootdir dentro de twrp/device/marca/codename) y abre el archivo. Al principio verás lo siguiente:

                                        on init export PATH /sbin

Añade debajo la siguiente línea:

                                        export LD_LIBRARY_PATH .:/sbin

Y debería quedar así:

                                        on init export PATH /sbin export LD_LIBRARY_PATH .:/sbin

Guarda los cambios y sal. Sigamos trabajando:

Ahora llega lo complicado. Hay que añadir líneas (flags) de TWRP. Cuesta un poco saber qué líneas añadir. 

Lo que haremos será ir al final del archivo BoardConfig y escribiremos la siguiente etiqueta: #TWRP

Hecho esto añadiremos las flags. Son las siguientes:

• DEVICE_RESOLUTION :=  ~indica la resolución de nuestro dispositivo. Debes elegir entre las dimensiones que veas en la carpeta twrp/bootable/recovery/gui/devices. Si no hay exacta para tu dispositivo, coge la que más se aproxime (siempre por debajo).
• TARGET_RECOVERY_FSTAB :=  ~indica la ruta del archivo twrp.fstab que crearemos posteriormente. Recomiendo que la ruta sea device/marca/codename/recovery/twrp.fstab.
• BOARD_HAS_NO_REAL_SDCARD := true  ~elimina funciones como "particionar SD". También ahorra espacio; útil si TWRP no ajusta en tu partición de recovery (por espacio). Recomiendo usar esta flag.
• TW_INTERNAL_STORAGE_PATH := "/data/media" ~indica la ruta de almacenamiento de medios (almacenamiento interno). La ruta puede variar y ser "/data/media/0" o diferente. Busca en tu dispositivo con un explorador root la ruta data/media y asegúrate. Sabrás que estás en la ruta correcta porque contendrá los archivos de memoria interna del teléfono (es la ruta equivalente a /mnt/sdcard).
• TW_INTERNAL_STORAGE_MOUNT_POINT := "data"  ~nombre del punto  de montaje de la partición indicada con la flag anterior. En el 99% de los casos es "data", pero mira el recovery.fstab de tu dispositivo para estar seguro de que nombre le dan.
• TW_EXTERNAL_STORAGE_PATH := "/external_sd"  ~lo mismo que con data/media, pero aplicado a la SD Externa. Asegura la ruta.
• TW_EXTERNAL_STORAGE_MOUNT_POINT := "external_sd"  ~lo mismo que con data, pero aplicado a la SD Externa. Asegura el nombre.

• TW_NO_REBOOT_RECOVERY := true  ~indica si queremos la opción "Reiniciar Recovery" al usar TWRP. Escribimos la línea si no queremos esa opción de reinicio.
• TW_NO_REBOOT_BOOTLOADER := true  ~lo mismo que la línea anterior, pero con bootloader. Si tu dispositivo no tiene bootloader, debes escribir la línea.
• TW_NO_USB_STORAGE := true  ~indica si queremos la opción de almacenamiento USB. Si tu dispositivo no tiene soporte de almacenamiento USB, escribiremos la línea.
• TW_NEVER_UNMOUNT_SYSTEM := true  ~indica que nunca se desmontará  la partición de sistema. Esta flag se necesita en algunos dispositivos Motorola.
• RECOVERY_SDCARD_ON_DATA := true  ~habilita el correcto manejo de data/media para los dispositivos que usen ese directorio como almacenamiento. Esta flag se usa para la mayoría de dispositivos con Android Honeycomb y aquellos con ICS de fábrica.
• TW_HAS_DOWNLOAD_MODE := true  ~indica si nuestro dispositivo tiene modo download (descarga). Todos los Samsung tienen esta función.
• TW_NO_BATT_PERCENT := true  ~elimina la función de mostrar porcentaje de batería al usar TWRP. Útil si tu dispositivo no lo soporta correctamente.
• RECOVERY_GRAPHICS_USE_LINELENGTH := true ~arregla gráficos de aspecto rasgado en algunos dispositivos. No sabrás si usarlo hasta probar TWRP por primera vez.

Hay algunas flags más, pero he puesto las que veo más importantes y las que entiendo. He separado las que para mí son básicas y de uso obligatorio arriba. Puedes ver más flags aquí o buscando en Google; no voy a buscar todas las flags que hay.

Aquí tenéis un ejemplo de las líneas que añadí para mi dispositivo:

 También puedes buscar dispositivos similares al tuyo con OmniROM o TWRP y mirad el BoardConfig de su device tree.

Aquí tienes el ejemplo más básico de flags usadas.

Hechos los cambios, guarda y cierra.

Recovery.fstab

Para esto lo más sencillo es coger y en twrp/device/marca/codename creamos una carpeta llamada "recovery". Dentro, creamos un archivo llamado twrp.fstab.

Ahora abrimos el archivo, y primero que todo escribiremos los mount points de nuestro dispositivo. Los tenéis en la carpeta rootdir que tuvimos que visitar en un paso anterior, en el archivo llamado fstab. Son las líneas que digan algo así como "dev/block/..."

Pues habrá que copiarlas a twrp.fstab, pero con orden diferente. Aqúi podréis ver la diferencia de formato:

- fstab.qcom

- twrp.fstab

*Atención, os habréis fijado que en el fstab.qcom salen menos mount points que en el de twrp, eso es porque en ese archivo no salen todos. Puedes ver los demás en el archivo recovery.fstab que está al desempaquetar un recovery (recovery.img) para tu dispositivo (es muy fácil)*

Como veis primero pondremos el nombre de la partición, luego el formato, y luego la ruta. Cuando lo tengas tocará añadir flags. ¡Ojo! No escribas las flags que aparecen en el "fstab.qcom".  

Las flags se añaden al final de cada línea de montaje (depués de flags=). Las flags solo afectan a la línea en la que estén, es decir, haremos flags para cada línea. Las separamos de la ruta de montaje mediante espacios. Si usamos varias flags en un misma línea, las debemos separar con punto y coma (;).

Un ejemplo del formato es este:

                          flags=display="Micro SDcard";storage;wipeingui;removable

Aquí dejo las flags disponibles para usar:

• removable  ~ literalmente: indica que la partición puede no estar presente en la prevención de errores de montaje mostrados durante el arranque. No sé explicarlo, pero esta flag la añadimos en external_sd y en usbstorage (también USB-OTG, depende del dispositivo). 
• storage  ~indica que la partición se puede usar como almacenamiento, lo que la habilitará para usarla para almacenar backups, etc. Sobra decir que esta se usa en external_sd y usbstorage (también USB-OTG).
• backup=1  ~indica que dicha partición puede estar listada en la opción backup/restore. Si en vez de 1 ponemos 0, indicará que no queremos que aparezca.
• wipeingui  ~hace que dicha partición aparezca en el menú de wipes en el menú de TWRP. Se añade en external_sd (también puedes añadirla en usbstorage).
• display=  ~indica el nombre con el que aparecerá la partición en los menús de TWRP. El nombre hay que ponerlo entre comillas, por ejemplo, "Micro SDcard".
• length=  ~solo se aplica a data. Detrás del igual se escribe un número. El número que debes poner está en el fstab.qcom (suele ser 16384)
• subpartitionof=  ~lo usamos cuando hay subparticiones. En el ejemplo que puse de twrp.fstab se usa, ya que hay varias particiones efs. Saber cuándo usarla en fácil si miras el ejemplo.

Esas serían todas. Hay algunas más, pero por lo que he visto, estas son las que se usan. En algunas he dicho donde se usan, pero ten en cuenta que para tu dispositivo puede variar, o puedes hacerlo como tu quieras en algunas, pero ten cuidado, no hagas ninguna locura ;-)
Por ello, recomiendo siempre mirar el de algún dispositivo similar al tuyo para ver cómo lo ha hecho.

Una vez terminado, guarda cambios y cierra

*Recomiendo crear el archivo twrp.fstab en esa carpeta (twrp/device/marca/codename/recovery) porque así ya coincide con la flag del BoardConfig.mk y con la línea añadida al device.mk. Si creaste el archivo en otra carpeta, edita la ruta en esos dos archivos*

Hecho todo esto, habremos añadido el código TWRP y estaremos listos para compilar el recovery.


6. Compilar el Recovery:

Este es el ansiado paso final con el que crearemos el custom recovery para nuestro dispositivo. Para ello ejecuta en Terminal:

                                      cd twrp *Si ya estás situado no hace flata*
                                      . build/envsetup.sh
                                      lunch
Ahora localiza tu dispositivo (saldrá algo como cm_codename-userdebug, u omni_codename-userdebug; depende de qué source hayas usado) por su codename, que en mi caso sería loganreltexx (saldría así cm_loganreltexx-userdebug) y miramos el número que tiene. Lo escribimos y le damos enter. Luego para compilar hay varias opciones:

1) Comando Común:

                                      make clean && make -j# recoveryimage
Sustituimos la almohadilla (#) por el número de procesadores que tenga nuestra PC +1. Es decir, si es un dual-core ejecutaremos con -j3. Tras ello empezará a compilar el archivo "img" del recovery.


2) Para Zip Flasheable:

Por otro lado, si en vez del archivo ".img" quieres hacerlo por zip flasheable, ejecutaremos el siguiente comando:

                                     make clean && make -j# recoveryzip
Hacemos lo mismo con la almohadilla.Tras este comando se habrá creado un archivo zip que instalaremos por modo recovery para tener TWRP.


3) Para algunos Samsung:

Y por otro lado más, si tu dispositivo es un Samsung que incluye el recovery en el kernel (boot.img) y no en su propia partición, deberás ejecutar el siguiente comando.

*Sabrás si tu dispositivo no tiene partición propia si al mirar el recovery.fstab no aparece partición recovery*

                                    make -j# bootimage
Hacemos lo mismo con la almohadilla. Al terminar se habrá creado un archivo ".img" que será el kernel con el TWRP incluido.

---------------------------------------------------------------------------------------------

La compilación en cualquiera de las variantes tardará unos veinte minutos, todo depende de la potencia que tenga tu PC. Cuando termine, si todo ha ido bien, tendrás el archivo en out/target/product/codename. En mi caso estaría en out/target/product/loganreltexx.

¡Listo! Ya has compilado TWRP