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 solicitud de revisiones y el seguimiento de cambios con Gerrit.

Requisitos previos

Antes de comenzar, asegúrate de haber hecho lo siguiente:

Recursos

  • A fin de obtener detalles sobre Repo y Git, consulta la página de Herramientas de control de código fuente.
  • Para obtener más información sobre las diferentes funciones que se pueden desempeñar en la comunidad de Código abierto de Android, consulta la página Funciones dentro del proyecto.
  • Si quieres obtener información sobre licencias para contribuir con código en la plataforma de Android, consulta la página Licencias.

Para colaboradores

Cómo realizar la autenticación con el servidor

Si compartes una dirección IP con otros usuarios, se pueden activar cuotas incluso con patrones de uso normales. Esto puede ocurrir, por ejemplo, si muchos usuarios sincronizan clientes nuevos desde la misma dirección IP en un período corto. El acceso autenticado utiliza una cuota distinta para cada usuario, sin importar la dirección IP. Para obtener información sobre cómo activar el acceso autenticado, consulta Cómo usar la autenticació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 fuentes final.

Cómo realizar el cambio

Modifica los archivos fuente y valida los cambios.

Confirma los cambios en tu repositorio local con los siguientes comandos:

git add -A
git commit -s

Descripciones de los cambios

  • Línea 1: Encabezado

    Proporciona un resumen de una línea (50 caracteres como máximo).

    Gerrit y Git usan ese formato para varias pantallas. Es la parte más importante y densa del mensaje de confirmación. Considera usar prefijos para describir el área que modificaste y, luego, describir el cambio que hiciste en esta confirmación, como el que se muestra a continuación con el prefijo ui:

    ui: Removes deprecated widget

  • Línea 2: Espacio en blanco

    Deja esta línea siempre en blanco.

  • Línea 3: Cuerpo

    Escribe una descripción más larga que comience en esta línea.

    Debe tener un máximo de 72 caracteres. Describe qué problema resuelve el cambio y cómo lo hace. Si bien esta descripción es opcional cuando implementas funciones nuevas, más tarde será muy útil para otros colaboradores si hacen referencia a este cambio; en especial, para las depuraciones.

    Incluye una nota breve sobre cualquier suposición o información general que pueda ser importante cuando otro colaborador trabaje en esta función.

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.

El siguiente es un ejemplo de mensaje de confirmación:

Line 1, Headline - a short description

Line 3, Body - Add the detailed description of your patch here. Use as many lines
as needed. You can write an overall description, then list specifics.

I6e3c64e7a:Added a new widget.
I60c539a8f:Fixed the spinning image.
Si quieres leer un blog sobre descripciones de confirmaciones efectivas (con ejemplos), consulta la entrada Cómo escribir un mensaje de confirmación de Git (en inglés) de Chris Beams.

Cómo subir los cambios 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. Haz clic en el vínculo que te proporciona Repo para ver tu parche en el servidor de revisión, agregar comentarios o solicitar revisores específicos.

Cómo solicitar una revisión

Después de que subas los cambios en Gerrit, los propietarios correspondientes del código deben revisar el parche y aprobarlo. Busca a los propietarios del código en los archivos OWNERS.

A fin de encontrar los propietarios adecuados y agregarlos como revisores para el cambio que quieres realizar, sigue estos pasos:

  1. Selecciona el vínculo SUGGEST OWNERS en la IU de Gerrit para ver una lista de propietarios de código de los archivos en tu parche.

    vínculo de sugerencia de propietarios en Gerrit
    Figura 1: Sugerir vínculos de propietarios en Gerrit
  2. Agrega propietarios de código de la lista como revisores para tu parche.

Para determinar el estado de los archivos en tu parche, verifica los siguientes íconos junto a los archivos del parche.

  • (ícono de marca de verificación): Aprobado por el propietario de código
  • (ícono de cruz): No está aprobado por el propietario de código
  • (ícono de reloj): Aprobación pendiente por el propietario de código
Figura 2. Ejemplo de archivos con íconos que muestran el estado de aprobación del propietario de código

Cómo subir un parche de reemplazo

Supongamos que un revisor vio tu parche y solicitó una pequeña modificación. Puedes modificar tu confirmación dentro de Git, lo que generará 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 fuentes, y estos entran en conflicto con los tuyos, deberás reubicar tu parche sobre el HEAD nuevo del repositorio de fuentes. Para ello, ejecuta el siguiente comando:

repo sync

El comando repo sync recupera las actualizaciones del servidor de origen y, luego, intenta reubicar automáticamente tu HEAD en el nuevo HEAD remoto.

Si no se realiza correctamente el ajuste automático, hazlo de forma manual.

repo rebase

Otra herramienta que puedes usar para resolver el conflicto de reubicación es git mergetool. Cuando hayas combinado de forma correcta los archivos en conflicto, ejecuta este comando:

git rebase --continue

Una vez que se complete 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 el cambio automáticamente en el repositorio público. Otros usuarios pueden ejecutar repo sync para implementar la actualización en sus respectivos clientes locales.

Para 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 que se encuentran en 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 es posible que subas parches que provoquen el seguimiento de una nueva versión ascendente. Ten en cuenta que estos pueden ser cambios 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 se suelen actualizar con cada versión nueva).

Un caso interesante es Bionic. Gran parte del código es de BSD. Por lo tanto, a menos que el cambio se realice en código nuevo de Bionic, asegúrate de crear una corrección ascendente y, luego, extraer un archivo nuevo del BSD correspondiente.

Kernel de Android

Prefiere hacer cambios ascendentes. Para obtener orientación general, sigue los lineamientos de contribución del kernel de Android.

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.