Esta página se ha traducido con Cloud Translation API.

Enviar parches

Esta página describe el proceso completo de envío de un parche al Proyecto de código abierto de Android (AOSP), incluido cómo solicitar una revisión y realizar un seguimiento de sus cambios con Gerrit . Gerrit es un sistema de revisión de código basado en web para proyectos que utilizan Git. Gerrit fomenta un uso más centralizado de Git al permitir que todos los usuarios autorizados envíen cambios, que se fusionan automáticamente si pasan la revisión del código. Además, Gerrit facilita la revisión, mostrando los cambios uno al lado del otro en el navegador y permitiendo comentarios en línea.

Requisitos previos

Para comenzar, asegúrese de haber hecho lo siguiente:

Inicializó su entorno de construcción
Descargado la fuente
Creó una contraseña usando el generador de contraseñas.
Firmar los acuerdos de licencia de colaborador.

Recursos

Para obtener detalles sobre Repo y Git, consulte la página Herramientas de control de código fuente .
Para obtener información sobre los diferentes roles dentro de la comunidad de código abierto de Android, consulte la página de roles del proyecto .
Para obtener información sobre licencias sobre cómo contribuir con código a la plataforma Android, consulte la página Licencias .

Configurar Git

Para utilizar Gerrit, su correo electrónico debe estar asociado con una cuenta de Google registrada. Ejecute los siguientes comandos para configurar Git con un nombre y una dirección de correo electrónico asociados con una cuenta de Google registrada:

git config --global user.name Your Name
git config --global user.email your_email@gmail.com

Autenticar con el servidor

Si comparte una dirección IP con otros usuarios, se pueden activar cuotas incluso para patrones de uso habituales. Esto puede suceder cuando, por ejemplo, muchos usuarios sincronizan nuevos clientes desde la misma dirección IP en un corto período de tiempo. El acceso autenticado utiliza una cuota separada para cada usuario, independientemente de su dirección IP. Para leer sobre cómo activar el acceso autenticado, consulte Uso de la autenticación .

Iniciar una sucursal de repositorio

Para cada cambio que desee realizar, inicie una nueva rama dentro del repositorio Git correspondiente:

repo start NAME .

You can start several independent branches at the same time in the same repository. The branch NAME is local to your workspace and isn't included either on Gerrit or in the final source tree.

Make your change

Modify the source files, and test your changes.

For any changes made, follow License header best practices.

Commit your change

Commit the changes to your local repository with these commands:

git add -A
git commit -s

Cambiar descripciones

Línea 1: Titular
Proporcione un resumen de una línea (50 caracteres como máximo ).
Git y Gerrit utilizan este formato para varias pantallas. Es la parte más importante y densa de su mensaje de confirmación. Considere usar prefijos para describir el área que cambió, seguido de una descripción del cambio que realizó en esta confirmación, como esta que tiene ui como prefijo:
ui: Removes deprecated widget
Línea 2: en blanco
Mantenga esta línea en blanco, siempre.
Línea 3: Cuerpo
Escriba una descripción más larga, comenzando en esta línea.
Esto debe contener un máximo de 72 caracteres. Describe qué problema resuelve el cambio y cómo. Aunque esto es opcional al implementar nuevas características, será muy útil para otros más adelante si hacen referencia a este cambio, especialmente para la depuración.
Incluya una breve nota de cualquier suposición o información general que pueda ser importante cuando otro colaborador trabaje en esta función.

Un ID de cambio único y su nombre y correo electrónico, que se proporcionan durante repo init , se agregan automáticamente a su mensaje de confirmación.

A continuación se muestra un mensaje de confirmación de ejemplo:

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.

To read a blog about good commit descriptions (with examples), see How to Write a Git Commit Message by Chris Beams.

Upload to Gerrit

After you commit your change to your personal history, upload it to Gerrit with this command:

repo upload

If you started multiple branches in the same repository, you're prompted to select which ones to upload.

After a successful upload, Repo provides you with the URL of a new page on Gerrit. Click the link that Repo gives you to view your patch on the review server, add comments, or request specific reviewers for your patch.

Request a review

After you've uploaded your changes to Gerrit, the patch must be reviewed and approved by the appropriate code owners. Locate code owners in OWNERS files.

To find the appropriate code owners and add them as reviewers for your change, follow these steps.

Select the SUGGEST OWNERS link in the Gerrit UI to see a list of code owners for the files in your patch.

Figure 1. Suggest owners link in Gerrit
Add code owners from the list as reviewers for your patch.

To determine the status of the files in your patch, check for the following icons next to the files in the patch.

(checkmark icon): Approved by code owner
(cross icon): Not approved by code owner
(clock icon): Pending approval by code owner

**Figure 2.** Example of files with icons showing code owner approval status

Upload a replacement patch

Suppose a reviewer looked at your patch and requested a small modification. You can amend your commit within Git, which results in a new patch on Gerrit that has the same change ID as the original.

Note: If you made other commits since uploading this patch, you must manually move your Git HEAD.

git add -A
git commit --amend

Cuando carga el parche modificado, reemplaza el original tanto en Gerrit como en su historial de Git local.

Resolver conflictos de sincronización

Si se envían otros parches al árbol de fuentes que entran en conflicto con el suyo, cambie la base de su parche en la parte superior del nuevo HEAD del repositorio de fuentes. Para hacerlo, ejecute este comando:

repo sync

El comando repo sync recupera las actualizaciones del servidor de origen y luego intenta cambiar automáticamente la base de su HEAD al nuevo HEAD remoto.

Si el cambio de base automático no tiene éxito, realice un cambio de base manual.

repo rebase

Otra herramienta para solucionar el conflicto de rebase es git mergetool . Cuando haya fusionado con éxito los archivos en conflicto, ejecute este comando:

git rebase --continue

Una vez completada la rebase automática o manual, ejecute repo upload para enviar su parche rebasado.

Después de que se apruebe un envío

Después de que un envío pasa por el proceso de revisión y verificación, Gerrit fusiona automáticamente el cambio en el repositorio público. Otros usuarios pueden ejecutar repo sync para introducir la actualización en sus respectivos clientes locales.

Para proyectos upstream

Android hace uso de otros proyectos de código abierto, como el kernel de Linux y WebKit, como se describe en Administración de software de Android . Para la mayoría de los proyectos que residen en external/ , realice los cambios en sentido ascendente y luego informe a los mantenedores de Android de la nueva versión ascendente que contiene sus cambios.

También puede cargar parches que hagan que se realice el seguimiento de una nueva versión ascendente. Tenga en cuenta que estos cambios pueden ser difíciles de realizar si el proyecto se usa ampliamente en Android, como la mayoría de los más grandes que se mencionan a continuación, que generalmente se actualizan con cada versión.

Un caso especial interesante es Bionic. Gran parte del código proviene de BSD, por lo que, a menos que el cambio sea en un código nuevo para Bionic, realice una corrección ascendente y luego extraiga un archivo completamente nuevo del BSD apropiado.

núcleo de Android

Realice todos los cambios en sentido ascendente. Para obtener orientación general, siga las Pautas de contribución del kernel de Android y la página Desarrollar código de kernel para GKI .

UCI

Realice todos los cambios en el proyecto de ICU en external/icu (carpetas icu4c/ y icu4j/ ) en la página de inicio de ICU-TC . Consulte Envío de errores y solicitudes de funciones de la UCI para obtener más información. Agregue la etiqueta "android" a todas las solicitudes de Jira ascendentes.

CLDR

La mayoría de los datos lingüísticos en ICU provienen del proyecto Unicode CLDR . Envíe todas las solicitudes en sentido ascendente de acuerdo con Contribuir a CLDR y agregue la etiqueta "android".

LLVM/Clang/Compiler-rt

Realice todos los cambios en los proyectos relacionados con LLVM ( external/clang , external/compiler-rt , external/llvm ) en la página Infraestructura del compilador LLVM .

mksh

Realice todos los cambios en el proyecto MirBSD Korn Shell en external/mksh enviando un correo electrónico a miros-mksh en el dominio mirbsd.org (no se requiere suscripción para enviarlo allí) o en Launchpad .

AbiertoSSL

Realice todos los cambios en el proyecto OpenSSL en external/openssl en la página OpenSSL .

V8

Envíe todos los cambios al proyecto V8 en external/v8 en la página de problemas de V8 . Consulte Contribuir a V8 para obtener más detalles.

kit web

Realice todos los cambios en el proyecto WebKit en external/webkit en la página WebKit . Inicie el proceso presentando un error de WebKit . En el error, use Android para los campos Plataforma y SO solo si el error es específico de Android. Es mucho más probable que los errores reciban la atención de los revisores después de que se agrega una solución propuesta y se incluyen pruebas. Consulte Contribución de código a WebKit para obtener más detalles.

zlib

Realice todos los cambios en el proyecto zlib en external/zlib en la página de inicio de zlib .