En esta página, se describe el proceso completo para enviar un parche al Proyecto de código abierto de Android (AOSP), incluidos la revisión y el seguimiento de cambios con Gerrit.
Requisitos previos
-
Antes de seguir las instrucciones de esta página, debes inicializar tu entorno de compilación, descargar la fuente, crear una contraseña y seguir las instrucciones que se indican en la página del generador de contraseñas.
-
Para obtener más información acerca de Repo y Git, consulta la sección sobre desarrollo.
-
Para obtener más detalles sobre las diferentes funciones que puedes desempeñar en la comunidad de Código abierto de Android, consulta Funciones dentro del proyecto.
-
Si deseas contribuir con código a la plataforma de Android, lee la Información de licencia del AOSP.
-
Ten en cuenta que los cambios en algunos de los proyectos ascendentes que usa Android deben realizarse directamente en ese proyecto, como se describe en la sección Proyectos ascendentes.
Para colaboradores
Cómo realizar la autenticación con el servidor
Antes de subir contenido a Gerrit, debes establecer una contraseña que te identifique con el servidor. Sigue las instrucciones de la página del generador de contraseñas. Solo debes hacer esto una vez. Consulta Cómo usar la autenticación para obtener más información.
Cómo iniciar una rama de Repo
Por cada cambio que intentes realizar, debes comenzar una rama nueva dentro del repositorio Git relevante:
repo start NAME .
Puedes iniciar varias ramas independientes al mismo tiempo en el mismo repositorio. La rama NAME
es el directorio local de tu lugar de trabajo y no se incluye en Gerrit ni en el árbol de fuente final.
Cómo realizar el cambio
Una vez que hayas modificado los archivos de origen (y los hayas validado), confirma los cambios en tu repositorio local:
git add -A
git commit -s
Proporciona una descripción detallada del cambio en el mensaje de confirmación. Esa descripción se envía al repositorio público del AOSP, por lo que debes seguir estos lineamientos para escribir descripciones de listas de cambios:
-
Comienza con un resumen de una línea (50 caracteres como máximo) seguido de una línea en blanco. Gerrit y Git usan ese formato para varias pantallas.
-
A partir de la tercera línea, ingresa una descripción más larga, con un máximo de 72 caracteres. Describe qué problema resuelve el cambio y cómo lo hace. La segunda parte es opcional cuando se implementan funciones nuevas, aunque se recomienda usarla.
-
Incluye una nota breve sobre cualquier suposición o información general que pueda ser importante cuando otro colaborador trabaje en esa función.
El siguiente es un ejemplo de mensaje de confirmación:
Short description on first line More detailed description of your patch, which is likely to take up multiple lines.
Se agregan automáticamente al mensaje de confirmación un ID de cambio único, tu nombre y tu correo electrónico, tal como los proporcionaste durante repo
init
.
Cómo subir a Gerrit
Después de confirmar el cambio en tu historial personal, súbelo a Gerrit con el siguiente comando:
repo upload
Si comenzaste varias ramas en el mismo repositorio, se te pedirá que selecciones cuáles quieres subir.
Cuando se haya cargado correctamente, Repo te proporcionará la URL de una página nueva en Gerrit. Visita esa página para ver tu parche en el servidor de revisión, agregar comentarios o solicitar revisores específicos.
Cómo subir un parche de reemplazo
Supongamos que un revisor vio tu parche y solicitó una modificación pequeña. Puedes modificar la confirmación dentro de Git, lo que genera un parche nuevo en Gerrit con el mismo ID de cambio que el original.
git add -A
git commit --amend
Cuando subas el parche modificado, se reemplazará el original en Gerrit y en tu historial de Git local.
Cómo resolver conflictos de sincronización
Si se envían otros parches al árbol de fuente que estén en conflicto con los tuyos, deberás reubicar el parche sobre el HEAD
nuevo del repositorio de fuente. La manera más fácil de hacer eso es ejecutar
repo sync
Primero, este comando recupera las actualizaciones del servidor de origen y, luego, intenta restablecer automáticamente tu HEAD
en el HEAD
remoto nuevo.
Si no se realiza correctamente la reubicación automática, hazlo de forma manual.
repo rebase
El uso de git mergetool
puede ayudarte a resolver el conflicto de reubicación. Una vez que hayas combinado correctamente los archivos en conflicto, ejecuta lo siguiente:
git rebase --continue
Después de terminar la reubicación automática o manual, ejecuta repo
upload
para enviar tu parche reubicado.
Después de la aprobación de un envío
Cuando un envío pasa por los procesos de revisión y verificación, Gerrit combina automáticamente el cambio en el repositorio público. Otros usuarios pueden ejecutar repo sync
para implementar la actualización en su cliente local.
Proyectos ascendentes
Android utiliza varios proyectos de código abierto (por ejemplo, el kernel de Linux y WebKit), como se describe en la sección Administración de software de Android.
Para la mayoría de los proyectos external/
, realiza los cambios en sentido ascendente y, luego, informa a los encargados de mantenimiento de Android acerca de la versión ascendente nueva que contiene estos cambios. También puede ser útil subir parches que nos lleven hacia una versión ascendente nueva, aunque estos cambios pueden ser difíciles de realizar si el proyecto se usa mucho en Android, como la mayoría de los más grandes que se mencionan a continuación, que solemos actualizar con cada actualización.
Un caso interesante es Bionic. Gran parte del código es de BSD. Por lo tanto, a menos que el cambio sea en código nuevo de Bionic, preferiríamos ver una corrección ascendente y, luego, extraer un archivo nuevo del BSD correspondiente.
ICU4C
Realiza todos los cambios en el proyecto ICU4C en external/icu4c
desde la página principal de ICU-TC.
Consulta Submitting ICU Bugs and Feature Requests (solo disponible en inglés) para obtener más información.
LLVM/Clang/Compiler-rt
Realiza todos los cambios en los proyectos relacionados con LLVM (external/clang
, external/compiler-rt
, external/llvm
) desde la página de Infraestructura de compiladores de LLVM.
mksh
Realiza todos los cambios en el proyecto MirBSD Korn Shell en external/mksh
mediante el envío de un correo electrónico a miros-mksh
en el dominio mirbsd.org
(no se requiere suscripción) o a través de Launchpad.
OpenSSL
Realiza todos los cambios en el proyecto OpenSSL en external/openssl
desde la página de OpenSSL.
V8
Envía todos los cambios del proyecto V8 en external/v8
desde la página de problemas de V8.
Consulta Contributing to V8 (solo disponible en inglés) para obtener más información.
WebKit
Realiza todos los cambios en el proyecto WebKit en external/webkit
desde la página de WebKit. Para comenzar el proceso, presenta un error de WebKit.
En el error, ingresa Android
en los campos Platform y OS solo si el error es específico de Android. Es más probable que un informe de errores reciba la atención de los revisores después de que se agregue una propuesta de solución y se incluyan pruebas. Consulta Contributing Code to WebKit (solo disponible en inglés) para obtener más información.
zlib
Realiza todos los cambios en el proyecto zlib en external/zlib
desde la página principal de zlib.