Repo init android что это

Repo command reference

Repo usage takes the following form:

Optional elements are shown in brackets [ ]. Once Repo is installed, you can get information about any command by running

Many commands take a project list as an argument. You can specify project-list as a list of names or a list of paths to local source directories for the projects:

Contents

Installs Repo in the current directory. This creates a .repo/ directory that contains Git repositories for the Repo source code and the standard Android manifest files. The .repo/ directory also contains manifest.xml , which is a symlink to the selected manifest in the .repo/manifests/ directory.

-u : specify a URL from which to retrieve a manifest repository. The common manifest can be found at git://android.git.kernel.org/platform/manifest.git

-m : select a manifest file within the repository. If no manifest name is selected, the default is default.xml.

-b : specify a revision, i.e., a particular manifest-branch.

Note: For all remaining Repo commands, the current working directory must either be the parent directory of .repo/ or a subdirectory of the parent directory.

Downloads new changes and updates the working files in your local environment. If you run repo sync without any arguments, it will synchronize the files for all the projects.

When you run repo sync , this is what happens:

If the project has never been synchronized, then repo sync is equivalent to git clone . All branches in the remote repository are copied to the local project directory.

If the project has already been synchronized once, then repo sync is equivalent to:

where BRANCH is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.

If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, git rebase —continue ) to resolve the conflicts.

After a successful repo sync , the code in specified projects will be up to date with the code in the remote repository.

-d : switch specified projects back to the manifest revision. Helpful if the project is currently on a topic branch, but the manifest revision is temporarily needed.

-s : sync to a known good build as specified by the manifest-server element in the current manifest.

-f : proceed with syncing other projects even if a project fails to sync.

upload

For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.

After you select one or more branches, all commits on the selected branches are transmitted to Gerrit over an SSH connection.You will need to configure an SSH key to enable upload authorization. Visit SSH Keys within the user settings panel to register your public keys with Gerrit. To enable password-less uploads, consider using ssh-agent on your client system.

When Gerrit receives the object data over its SSH server, it will turn each commit into a change so that reviewers can comment on each commit individually. To combine several “checkpoint” commits together into a single commit, use git rebase -i before you run repo upload.

If you run repo upload without any arguments, it will search all the projects for changes to upload.

To make edits to changes after they have been uploaded, you should use a tool like git rebase -i or git commit —amend to update your local commits. After your edits are complete:

Make sure the updated branch is the currently checked out branch.

Use repo upload —replace PROJECT to open the change matching editor.

For each commit in the series, enter the Gerrit change ID inside the brackets:

After the upload is complete the changes will have an additional Patch Set.

Shows outstanding changes between commit and working tree using git diff .

download

Downloads the specified change from the review system and makes it available in your project’s local working directory.

For example, to download change 1241 into your platform/frameworks/base directory:

A repo sync should effectively remove any commits retrieved via repo download . Or, you can check out the remote branch; e.g., git checkout m/master .

Note: There is a slight mirroring lag between when a change is visible on the web in Gerrit and when repo download will be able to find it, because changes are actually downloaded off the git://android.git.kernel.org/ mirror farm. Hence there will always be a lag of approximately 5 minutes before Gerrit pushes newly uploaded changes out to the mirror farm.

forall

Executes the given shell command in each project. The following additional environment variables are made available by repo forall :

REPO_PROJECT is set to the unique name of the project.

REPO_PATH is the path relative to the root of the client.

REPO_REMOTE is the name of the remote sstem from the manifest.

REPO_LREV is the name of the revision from the manifest, translated to a local tracking branch. Used if you need to pass the manifest revision to a locally executed git command.

REPO_RREV is the name of the revision from the manifest, exactly as written in the manifest.

-c : command and arguments to execute. The command is evaluated through /bin/sh and any arguments after it are passed through as shell positional parameters.

-p : show project headers before output of the specified command. This is achieved by binding pipes to the command’s stdin, stdout, and sterr streams, and piping all output into a continuous stream that is displayed in a single pager session.

-v : show messages the command writes to stderr.

prune

Prunes (deletes) topics that are already merged.

start

Begins a new branch for development, starting from the revision specified in the manifest.

The BRANCH_NAME argument should provide a short description of the change you are trying to make to the projects.If you don’t know, consider using the name default.

The PROJECT_LIST specifies which projects will participate in this topic branch.

Note: “.” is a useful shorthand for the project in the current working directory.

status

Compares the working tree to the staging area (index) and the most recent commit on this branch (HEAD) in each project specified. Displays a summary line for each file where there is a difference between these three states.

To see the status for only the current branch, run repo status . The status information will be listed by project. For each file in the project, a two-letter code is used:

In the first column, an uppercase letter indicates how the staging area differs from the last committed state.

letter	meaning	description
—	no change	same in HEAD and index
A	added	not in HEAD, in index
M	modified	in HEAD, modified in index
D	deleted	in HEAD, not in index
R	renamed	not in HEAD, path changed in index
C	copied	not in HEAD, copied from another in index
T	mode changed	same content in HEAD and index, mode changed
U	unmerged	conflict between HEAD and index; resolution required

In the second column, a lowercase letter indicates how the working directory differs from the index.

Источник

Что на самом деле выполняет репо init и repo sync?

Я разместил этот вопрос у Энтузиастов Android, но решил, что это неправильное место, чтобы спросить, поэтому я удалил его оттуда и попросил его «снова» здесь.

Это такой вопрос о нобе, и простите меня, если это так, но я просто хочу четко понять основные понятия. Чтение справки репо и справочная страница команды репо на Google не очень просвещают. Я понял некоторые фрагменты с справочной страницы Google, но мне все еще нужны дополнительные разъяснения.

Следуя инструкциям по загрузке источника Android, я выполнил эти две команды в оболочке Ubuntu: (Я ухаживал за всеми предпосылками для среды.)

После того, как вы вернулись на пол дня для репо, чтобы закончить загрузку, я закончил с 19G загруженного материала в каталоге android4.2.2. Итак, что именно произошло, и почему он достиг 19G, когда Google сказал, что я должен ожидать только около 8G исходных файлов?

repo – скрипт оболочки python для git , его страница источника Google определяет его как

Repo – Многопользовательский репозиторий

Команда repo init инициализирует репо в текущем каталоге. Таким образом, он загружает самый последний источник репо и файл manifest.xml который описывает структуру каталогов репозиториев git и сохраняет их все в .repo в текущем каталоге. В вашем случае вы использовали необязательный аргумент -b который используется для выбора ветви для проверки. По умолчанию (т. -b Когда аргумент -b не используется) используется мастер-ветвь.

repo sync обновляет рабочее дерево до последней версии. Таким образом, он синхронизирует локальные каталоги проектов с удаленными репозиториями, указанными в файле манифеста. Если локальный проект еще не существует, он клонирует новый локальный каталог из удаленного репозитория и настраивает ветви отслеживания, как указано в манифесте. Если локальный проект уже существует, он обновит удаленные филиалы и обновит новые локальные изменения поверх новых удаленных изменений. -j используется для задания количества выполняемых параллельных заданий. Значение по умолчанию может быть определено в манифесте, а также может быть переопределено в командной строке, как в вашем случае.

Почему он достиг 19G, когда Google сказал, что я должен ожидать только около 8G исходных файлов?

Это должно быть потому, что помимо исходных файлов вы получите всю историю Android с самого начала времени 🙂

Источник

Общие принципы сборки Android из исходных кодов

Содержание статьи

Пересборка Android из исходных кодов требуется для многих задач. Это может быть потребность в недостающих модулях ядра Linux, компиляция с более агрессивными опциями оптимизации, создание и отладка собственных модулей, а также различные кастомизации под себя. В этой статье я попытаюсь рассказать об общих принципах сборки Android на примере чистого AOSP (Android Open Source Project), а также его модификации CyanogenMod.

Введение

Итак, мы будем собирать Android из исходных кодов. Условно разделим этот занимательный процесс на три шага:

1. Подготовка системы.
2. Скачивание исходников.
3. Собственно сама сборка.

В процессе мы скомпилируем Android для четырех разных устройств, включая официальный Galaxy Nexus, поддерживаемый командой CyanogenMod LG Optimus Black, а также Samsung Galaxy Y и Motorola DEFY, для которых существуют только неофициальные порты CyanogenMod, развиваемые независимыми разработчиками.

Предварительные ласки, или настройка системы

Для начала определимся с тем, что нам потребуется для сборки AOSP из исходников. Во-первых, Linux, желательно Ubuntu, и, если хочешь собрать Android версии 2.3.x (Gingerbread) и выше, ОС должна быть 64-разрядной. Замечу также, что по заявлению команды разработчиков, «беспроблемная» сборка сейчас возможна только под Ubuntu версий 10.04–11.10, тогда как на 12.04 соберется только последняя версия Android. Тем не менее я проводил все эксперименты на 12.04 и не встретил каких-либо ошибок или некорректной работы прошивки.

Кроме того, нужно позаботиться о достаточном количестве дискового пространства и оперативной памяти. Исходники Android весят около 14 Гб, плюс в процессе сборки испарится еще где-то 15 Гб. Оперативной памяти потребуется не меньше 2 Гб, да и то вкупе с областью подкачки, размером 3–4 Гб. Если все эти требования удовлетворены, можно приступить к подготовке системы. Для начала установим необходимые пакеты:

Немного слов о JDK: рекомендуется использовать Oracle Java JDK, но, так как он больше не поставляется в репозиториях Ubuntu, его нужно скачать с сайта Oracle и установить самостоятельно (goo.gl/N4IB2). Кроме того, нам понадобится гугловский инструмент для работы с репозиториями repo, представляющий собой Python-обертку вокруг системы контроля версий git:

Теперь система готова, и нам нужны исходники Android.

Загрузка исходников

Перечисленные манипуляции по настройке системы справедливы для сборки любой версии и любой модификации Android. Дальнейшие наши действия уже зависят от наших желаний. Для примера давай начнем со сборки AOSP для Galaxy Nexus. Это типичнейший вариант. Для этого создадим каталог (можешь назвать его как угодно, это непринципиально), в котором собственно и будут лежать исходники:

Далее необходимо инициализировать репозиторий с помощью repo:

На этом этапе repo попросит ввести имя и e-mail, что делать совсем не обязательно. По умолчанию repo будет настроен на ветку master указанного репозитория (это последняя версия системы). Если тебе нужны исходники другой версии, укажи ее с помощью ключа ‘-b’. Например:

Далее можно приступить к загрузке файлов:

Чтобы загрузка происходила в несколько потоков, можно указать опцию -j#, где # — число потоков. Сам процесс загрузки довольно длительный (на канале 1 Мб/с загрузка заняла больше трех часов), поэтому можешь спокойно идти заниматься своими делами. В случае если загрузка оборвется, достаточно будет вновь выполнить «repo sync» для ее восстановления с прерванного места. После окончания загрузки на экран будет выведена надпись вида «Syncing work tree: 100% (305/305) done» (см. скриншот 1). Это значит, что уже можно приступать к сборке.

Скриншот 1. Успешная загрузка исходников

Хакер #168. Спуфинг в воздухе

Сборка

Перед тем как начать процесс компиляции, мы должны выполнить команды скрипта envsetup.sh для установки всех необходимых переменных окружения и функций. Для этого переходим в каталог с исходниками (у меня

/android/system) и выполняем:

Только в случае успешного выполнения этого скрипта можно вызывать команду:

Она предназначена для выбора цели сборки или, говоря другими словами, конкретного устройства. Вызвав ее без параметра, устройство можно будет выбрать из списка. В нашем случае нужно указать full_maguro-userdebug, где maguro — кодовое имя Galaxy Nexus GSM/HSPA+. После этого можно запустить процесс компиляции:

Здесь 4 — число потоков компиляции. Это значение рекомендуется выбирать между максимальным и удвоенным максимальным числом аппаратно поддерживаемых потоков (для процессоров AMD это число равно количеству ядер процессора, для Intel это число нужно умножить на два), с учетом того что на каждый поток уйдет как минимум 2 Гб оперативки, которая, кстати говоря, может закончиться в самый неподходящий момент.

Лично у меня процесс рухнул на сборке библиотеки libwebcore.so из-за нехватки памяти. После увеличения свопа с 2 до 3 Гб результат был тем же. Пришлось собирать этот модуль отдельно и в один поток: make libwebcore -j1, после чего вновь начинать общую сборку. Возможны и другие ошибки, но, как правило, они уже изучены, и решение можно найти в Гугле. При успешной компиляции последняя строка вывода будет содержать путь и размер образа (скриншот 2).

Скриншот 2. Сборка AOSP завершена

На этом сборка AOSP закончена. Но что, если нам нужна прошивка для другого аппарата? Так вот, чистый AOSP ты сможешь собрать только под «гугловские» аппараты плюс Sony Xperia S. Конечно, есть решения и для других девайсов, но для таких устройств лучше и легче всего собрать модификацию AOSP — CyanogenMod.

Установка CyanogenMod через CWM

Установку кастомных прошивок следует выполнять из ClockworkMod Recovery (CWM). Это кастомная консоль восстановления, позволяющая устанавливать прошивки с любыми цифровыми подписями. Мануал о том, как установить CWM на твой конкретный девайс, ищи на xda-dev или просто погугли. Я опишу лишь установку CyanogenMod с его помощью.

Скриншот 5. Главное меню CWM

Для начала выключи телефон и включи его с зажатыми кнопками + + (комбинация может отличаться для разных устройств). После этого ты увидишь меню, показанное на скриншоте 5. Для навигации используй клавиши громкости, для выбора выделенного пункта — клавишу(или ). Для начала выполни сброс до заводских настроек с помощью пункта wipe data / factory reset, а затем смонтируй карту памяти с помощью меню mounts and storage -> mount USB storage и скопируй на нее файл прошивки. Далее выбери пункт «install zip from sdcard» и выбери файл с прошивкой (скриншот 6). Готово! CyanogenMod установлен.

Скриншот 6. Выбор архива для прошивки

CyanogenMod

CyanogenMod (далее CM) — это форк AOSP со множеством модификаций, направленных на улучшение производительности и стабильности, массой дополнительных функций и полезных плюшек, которых нет в стандартной прошивке. Разработка CyanogenMod ведется почти под все самые популярные аппараты (список здесь: www.cyanogenmod.com/devices), а это значит, что каждый может собрать CyanogenMod под конкретное устройство из исходных кодов, которые всегда доступны для скачивания. CyanogenMod пользуется огромной популярностью, поэтому неофициальные порты прошивки можно найти и для множества других аппаратов, помимо официально поддерживаемых.

Существует несколько поддерживаемых версий CM, включая CyanogenMod 7 (на базе Gingerbread, для маломощных бюджетных устройств), CM9 (на базе ICS) и до сих пор разрабатываемая CM10 (на базе JB). Сборка каждой из версий CM происходит одинаково. Для примера мы скомпилируем CM10 для LG Optimus Black, но я постараюсь упомянуть обо всех отличиях и для других версий CM. Стоит заметить, что компиляция CM ничем не отличается от AOSP, поэтому действия по подготовке системы будут теми же, плюс потребуется ADB, который можно скачать отдельно или в комплекте Android SDK. Процесс получения исходников аналогичен, за исключением адреса:

Если тебе нужны исходники другой версии, то просто укажи ее имя после ключа ‘-b’: «-b gingerbread» для CM7, «-b ics» для CM9. Ждать придется не меньше, чем при скачивании AOSP, так что можешь спокойно заниматься своими делами. По умолчанию загрузятся только сорцы самого CM без специфических для конкретных устройств файлов, которые можно получить с помощью другой команды:

Здесь p970 — кодовое имя LG Optimus Black (как его узнать? Как вариант, можно посмотреть на download.cyanogenmod.com слева в колонке Devices). Кроме исходников устройства, также в большинстве случаев понадобятся проприетарные библиотеки, исходников которых нет (поставщик железа их не предоставил). Поэтому их придется извлечь с устройства. Для этого подключаем к компьютеру наш девайс с помощью USB-кабеля (тут-то нам и нужен ADB), на котором уже должна быть установлена последняя официальная версия CM, и запускаем скрипт extract-files.sh:

Также нам потребуются закрытые приложения RomManager и Terminal Emulator, которые можно получить так:

А вот теперь все! Можно собирать:

Здесь brunch — один из хуков, создаваемых envsetup.sh. Пока идет процесс сборки, мы попробуем разобраться, что же такое brunch, а также в других хитрых функциях, используемых в CM.

Агрессивные оптимизации

Чтобы повысить производительность прошивки, ты можешь попробовать применить более агрессивные опции оптимизации компилятора. Для этого вместо «mka bacon» запусти такую команду:

Но это на твой страх и риск, так как можешь нарушить совместимость сборки с софтом и железом.

Ускорение сборки

Если ты соберешь и AOSP, и CM, то обязательно заметишь, что CM компилируется значительно быстрее. И ты наверняка заметил, что при сборке AOSP использовалась команда make, а тут — brunch. Если разобраться, команда brunch имя_устройства является эквивалентом такой команды:

Что же тогда такое «mka bacon»? А в этой команде и спрятана вся соль. Это функция, содержащая следующую команду:

Она переключает планировщик процессора в режим SCHED_BATCH и повышает приоритет текущей задачи, так что ей отдается больше времени на исполнение, а также устанавливает максимальный приоритет на ввод-вывод для текущей задачи и запускает make, распараллеливая его на все процессоры. За счет этого сборка CM проходит быстрее, но при этом пользоваться компом во время сборки становится нереально.

Если ты планируешь часто пересобирать прошивку, то есть смысл настроить ccache, чтобы ускорить процедуры пересборки. Для этого установи одноименный пакет и добавь в

/.bashrc такие строки:

И сразу же после загрузки исходного кода выполни:

Значение 50G здесь для примера. Ты можешь указать произвольный размер кеша. Теперь вернемся к нашей сборке. В случае ее удачного завершения (скриншот 3) в каталоге

/android/cm/out/target/product/p960/ будет лежать файл с названием вроде cm-10-XXXXXXXXX-UNOFFICIAL-p970.zip. Это и есть наша прошивка, которую можно установить с помощью консоли восстановления (recovery).

Скриншот 3. Сборка CM завершена

• Существуют автоматизированные системы сборки Android с исходных кодов:goo.gl/i0pvm и goo.gl/yyaLN.
• Проприетарные файлы можно также извлечь из архива прошивки, а не с рабочего девайса. Это можно сделать с помощью скрипта unzip-files.sh, если таковой имеется в дереве устройства.
• В сборку CM не включены стандартные приложения от Google (gapps). Для их установки скачай отсюда архив и установи через CWM.

Сборка CyanogenMod для кастомного устройства

Не беда, если твоего девайса нет среди официально поддерживаемых. Как я уже говорил, ребята с XDA или 4PDA часто портируют CyanogenMod под свои устройства, поэтому неофициальный порт CM можно найти практически для любого устройства. Все исходные тексты и конфигурационные файлы для девайса носят имя «дерево устройства» (device tree) и должны лежать в каталоге «device/производитель/имя_устройства» исходников CM. Для того чтобы собрать CyanogenMod под свое устройство, ты должен найти в Сети (в большинстве случаев находится на GitHub) дерево устройства и поместить его в соответствующий каталог.

Для примера возьмем Samsung Galaxy Y, для которого нет официального CM. На GitHub пользователя vivekkalady (goo.gl/soi4I) я нашел дерево устройства этого аппарата для CM7. Каковы мои действия? Я должен скачать содержимое репозитория в каталог «device/samsung/totoro» (totoro — кодовое имя Galaxy Y), а затем запустить процесс компиляции. Но где брать проприетарные файлы? Их можно извлекать только с девайса с рабочим официальным CM, что невозможно в нашем случае. Часто эти файлы уже есть в дереве устройства, но я их там не нашел, зато нашел в другом репозитории на GitHub того же vivekkalady (goo.gl/5JvIg). Далее остается скопировать их в каталог «vendor/samsung/totoro», получить RomManager и Terminal Emulator, как показано выше, и начать сборку:

Другие авторы портов могут выложить в Сеть все исходники CM вместо отдельного дерева устройства. Например, порт CM10 для Motorola Defy (официально для нее поддерживается только CM9) лежит вместе с исходниками CM10 в GitHub пользователя с ником Quarx с 4pda.ru. Для сборки этого порта делаем следующее:

Проприетарные файлы уже находятся в исходниках, так что искать или извлекать их не требуется. Остается только скачать «несобираемое» ПО и запустить процесс сборки:

Кстати, по причине залоченного загрузчика кастомные прошивки для DEFY работают на ядре, загружаемом на лету с помощью модуля kexec. Это ядро носит экспериментальный статус, и его придется прошивать отдельно уже после установки самой прошивки (файл 2ndboot_06.10.zip на нашем диске).

Скриншот 4. CM10 на Defy

• Официальная страница проекта AOSP;
• wiki-статья о сборке CyanogenMod;
• сборка Android под x86;
• здесь можно почитать подробнее о дереве устройства:;
• подробнее о breakfast, lunch и brunch.

Вместо итогов

Если тебе не удалось собрать Android с первого раза — не нужно расстраиваться. Наберись терпения и продолжай. Свою первую прошивку я собрал через неделю после первой попытки. Я постарался описать основные принципы сборки Android из исходных кодов, но большое количество важной информации все же осталось за кадром. В сносках я оставил несколько ссылок, по которым есть дополнительная информация. На этом у меня все. Удачной сборки!

Источник