Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Cómo enviar parches

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

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.