java - studio - Código fuente y repositorio de Android: qué sucede exactamente al obtener el código

programa para convertir jar a apk

Question

Me he encontrado con muchas preguntas breves sobre aspectos mínimos del uso del repo para obtener una fuente de Android o definiciones muy amplias de lo que hace el repo y, como resultado, no entiendo realmente lo que sucede cuando uso el repo . Estoy siguiendo las instrucciones en el sitio de Android Source . Lo hago todo mientras repodir en mi repodir por lo que todas las menciones de los archivos son relativas a esto.

Inicial y sincronización de repositorio:

repo init -u https://android.googlesource.com/platform/manifest
repo sync

Una vez que esto se completa, mi carpeta está llena de carpetas de tipo Android ( bionic , de bootable , etc.) y una carpeta oculta .repo . Cabe destacar que hay una carpeta llamada ics-mr1 que se relaciona con una versión específica y contiene principalmente las mismas carpetas en mi repodir dentro de sí misma.

Tire hacia abajo una rama específica:

repo init -u https://android.googlesource.com/platform/manifest -b gingerbread
repo sync

Esto se completa relativamente rápido y el cambio principal que veo es que ahora hay una carpeta llamada gingerbread (todas las carpetas originales parecen permanecer).

Ahora intento esto y toma EDAD:

repo init -u https://android.googlesource.com/platform/manifest -b android_4.2.2_r1
repo sync

Después, todavía contiene el mismo gingerbread y ics-mr1 y algunas nuevas carpetas aleatorias (como abi ) pero nada de lo que parece ser de esa nueva versión.

La pregunta

De los resultados de esto, veo que realmente no entiendo qué están haciendo exactamente mis acciones y cómo lograr lo que estoy tratando de hacer.

¿Cómo puedo obtener una versión local de toda la rama master de la fuente y luego cambiar correctamente entre las ramas según lo considere conveniente? La forma en que estoy en este momento parece incorrecta, ya que los archivos que quedan después de los cambios en las sucursales parecen ilógicos.

Además, ¿existe una manera eficiente de tener copias locales de numerosas sucursales simultáneamente de modo que pueda comparar los componentes de cada una (obviamente sin volver a descargarlas cada vez)?

Estoy haciendo estas preguntas con grandes huecos en la comprensión (para las cuales no he podido encontrar información clara y coherente), por lo que cualquier información adicional sobre la respuesta para ayudar a comprender lo que realmente se está haciendo realmente sería valiosa.

Answer 1

inicio de repo

Ya que pareces ser muy inteligente, sabes que el repositorio es solo un script de python, ¿verdad? Puedes leerlo para ver exactamente cómo funciona. No he leído todo el tema, pero, básicamente, envuelve git y proporciona soporte para trabajar en múltiples repositorios de git. La idea es que exista un archivo de manifiesto que especifique los requisitos para diferentes versiones de Android. Cuando repo init con un argumento, mira qué repositorios de git necesita clonar y qué repositorios de git ya ha sincronizado, y qué ramas necesita recuperar una vez que haya obtenido los repositorios adecuados. Luego se encarga de mantener todos los repositorios que administra en las sucursales apropiadas. Piense en repo como agregar otra capa al flujo de trabajo de git estándar (con lo que supongo que está familiarizado).

La primera vez que use el repositorio, para obtener la rama maestra, debe usar

repo init -u https://android.googlesource.com/platform/manifest

Y luego necesitas sincronizar todos los archivos del servidor:

repo sync

Esto actualizará su directorio de trabajo actual al estado exacto especificado por la versión maestra del manifiesto que descargó. Para pagar una versión diferente del AOSP, utiliza:

repo init -b version_name

Esto actualiza el manifiesto al que contiene información sobre la versión de Android que desea (también llamada rama).

No olvides sincronizar.

Para cambiar a otra rama de manifiesto, repo init -b otherbranch puede usarse en un cliente existente. Sin embargo, como esto solo actualiza el manifiesto, es necesaria una posterior repo sync (o repo sync -d ) para actualizar los archivos del directorio de trabajo.

El comportamiento que está experimentando puede parecer extraño porque probablemente no esté acostumbrado a trabajar con un sistema que sobrescriba su estado local tan fácilmente. Cuando usas git, no debes init muchas veces en el mismo directorio . Otra opción es hacer nuevos directorios para cada proyecto. El propósito del directorio .repo es almacenar toda la información relevante para su configuración de repo actual (también como el directorio .git). De hecho, ejecutar repo init hace muchas cosas:

1. Descarga el manifiesto de la url especificada.
2. Intenta abrir o crear el directorio .repo.
3. Asegúrese de que su clave GPG está configurada.
4. Clona la rama especificada (que por defecto es REPO_REV si no se especifica ninguna).
5. Lo verifica
6. Revisa la sucursal apropiada para cada uno de los proyectos.

.repo la operación de clonación escribe sobre la información en la carpeta .repo . La razón por la que se tardan siglos después del primer comando que ejecuta:

repo init -u https://android.googlesource.com/platform/manifest
repo sync

Es porque tiene que descargar muchos gigabytes de información. Ahora, al pasar de la rama master al repositorio de gingerbread de gingerbread sabe que simplemente se deben eliminar aproximadamente 68 confirmaciones, que se pueden hacer muy rápidamente.

$ repo init -u https://android.googlesource.com/platform/manifest -b gingerbread
$ repo sync
...
.repo/manifests/: discarding 68 commits
...

La copia de seguridad de android_4.2.2_r1 significa que el repositorio debe descargar de nuevo toda la información que necesiten esos compromisos y también actualizar las sucursales actuales en todos los proyectos a los que se hace referencia. Esto tomará un largo tiempo; repo es el uso del disco de comercio para el tiempo de procesamiento.

¿De Verdad?

Ahora, esto presenta un problema: ¿qué sucede si desea comparar dos sucursales de repos a la vez? Esto es difícil porque cuando se repo init && repo sync se pierde la información antigua que estaba viendo. La respuesta es copiar la información relevante y luego repo init && repo sync nuevamente. Esto se volverá molesto muy rápido; afortunadamente, repo proporciona una manera de acelerar este proceso si tiene espacio en el disco.

Una estrategia para hacer que las cosas sean más rápidas es crear un espejo local en un directorio de área de workspace/master . Luego, verifique su rama deseada desde el espejo en un nuevo directorio, por ejemplo, área de workspace/gingerbread . Ahora puede cambiar entre sucursales simplemente cambiando al directorio apropiado.

Refleja el AOSP localmente:

cd workspace
mkdir master && cd master
repo init --mirror

causará que el repositorio refleje el servidor remoto en su máquina local. Luego, cuando desee cambiar a una nueva rama, puede:

mkdir ../gingerbread && cd ../gingerbread
repo init -b version_name --reference=../master

El resultado es un espacio de trabajo con una carpeta que contiene el espejo y una carpeta que contiene la rama de pan de jengibre que hace referencia al espejo cuando es posible.

La otra opción es simplemente inicializar y sincronizar la rama que desee, luego copiar la carpeta en otra ubicación y usar la copia para inicializar y sincronizar nuevamente. Repo solo debe descargar lo que falta.

Otros usos de repo:

Más allá de init , repo proporciona soporte para pasar comandos, como branch , a todos los diferentes repositorios de git en un manifiesto determinado para que no tenga que preocuparse por eso cuando trabaje con el código. También facilita la colaboración al facilitar el envío de sus cambios locales al sistema de revisión de código Gerrit. No estoy seguro de cuál es la razón oficial para dividir el AOSP en múltiples repositorios git, pero me imagino que se hizo para administrar los problemas de escalamiento del control de versiones y para mantener el proyecto sólido y tolerante a fallos (si alguien frena un repositorio de git, no destruye todo el AOSP). También es necesario proporcionar una forma en que los proveedores puedan contribuir de nuevo a la fuente y permitirles administrar sus propios repositorios de git, que simplemente pueden registrarse con / en un manifiesto general que tenga sentido. No respondí a sus preguntas en la línea de ítems, pero espero que proporcione algunos antecedentes.