Github android studio app

How to use GitHub with Android Studio

Table of Contents

What to contribute

Cloning the repository

Making the change

Forking the repository

Committing and pushing the change

Creating the pull request

• over 1 year ago

Android Studio makes it easy to push changes to your favorite Open Source, professional, or personal projects on GitHub. In this tutorial, we’ll learn how to use GitHub with Android Studio. We’ll use an Open Source contribution for context.

Android developers use Open Source projects to speed up development or enable functionality that is otherwise impractical to build. Therefore it’s essential to understand how to give back and improve the Open Source projects that we use.

Requirements

Selecting project

First of all, to which Open Source project should you contribute? You can contribute to any project, but, ideally, it’s one that you know and use.

What to contribute

Sometimes, during the usage of an Open Source library, we encounter bugs that we wish were fixed and missing features that we want added. When that happens, it’s tempting to request it to the maintainer(s) and hope for the best, or even search for another library. However, it’s essential first to consider contributing with that bug fix or feature we want. It’s often not as complicated as we may think.

Alternatively, we may want to contribute to the project in general and select a request that’s made by the community. In this case, the best way to find an idea is to look through the issues list and select an issue that seems simple enough for a first contribution.

For this tutorial, I’ll fix a bug that I encountered while testing the sample app. In this case, the sample app crashed when pressing an image inside the chat, instead of showing it in full screen.

Cloning the repository

With Android Studio, you don’t need to use the terminal to contribute to an Android project on GitHub. It has native integration with git and GitHub to allow most actions via the Android Studio UI.

When you open Android Studio, it offers the option to open a project from version control. That’s the option we’ll use.

After selecting that option, you can type the URL of the repository, press «Clone», and select a folder. After that, Android Studio will do all the work and open the project ready to go.

Making the change

Initially, the default branch will be selected, but often projects have a development branch that receives the changes before merging them to master. Let’s create a branch for our change based on that development branch. That is a better practice than using the development branch directly, to not risk polluting it.

To do that, click where it says «Git: [default branch]», select the development branch, click «New Branch from Selected», and choose a name for your branch.

After that, we can proceed with making the change we want. After debugging the project, I’ve identified that initializing Facebook’s Fresco library in the MessageListView class solves the issue.

Now that we fixed the issue, we’re ready to commit it and send a Pull Request to the main GitHub repository. The next step will show how to fork the repository, in case you don’t have permission to push a branch to the main repository, which is often the case if you’re not a maintainer of that project.

Forking the repository

If you’re not a maintainer of that repository, you can’t push your branch to it. You’ll need to fork it first and push the branch to your fork. To do this, go to the GitHub repository and press fork.

You’ll need the URL of your repository in the next step, as we’ll push the branch to it.

Committing and pushing the change

Now, we can commit our change. To do this, either press CMD+K (or CTRL+K on Windows), or navigate to Commit via the menu.

Review your changes in the screen provided, write a descriptive commit message, press the arrow on the «Commit» button, and select «Commit and push». That will take you to the screen where you’ll choose which repository the branch will be uploaded. If you’re a maintainer of the origin remote, you can press «Push» and skip to «Creating the pull request».

If you’re not a maintainer, you should press the «origin» label, which will allow you to define a new remote repository. After that, you still need to select the proper remote and press the «Push» button.

If you’re not yet authenticated, Android Studio will ask for your GitHub credentials.

After you authenticate, Android Studio will send the changes to your remote repository.

Creating the pull request

Now, go to your repository page on GitHub, and you’ll see a prompt to open a Pull Request with your newly pushed branch.

When you press that, it will take you to a Pull Request composer. Generally, it will already contain a template that you can follow to describe your PR and some instructions that you need to follow. Also, don’t forget to check out the contribution guidelines of the project if it has one.

Usually, GitHub will pick the master branch as a base, so don’t forget to switch it to the development branch, if it exists, as the image shows.

Wrapping up

Congratulations! You just learned how to contribute to an Open Source project using GitHub and Android Studio, without having to touch the command-line interface. After you’ve sent your Pull Request, the project’s maintainers will review it and ask for changes if needed, in which case you can follow the «Committing and pushing the change» step again.

At Stream, we have many Open Source Android projects in Kotlin and Java, and we’re happy to receive and help you with your contributions.

Источник

Прокачиваем Android проект с GitHub Actions. Часть 1

Это пост для тех, кто заинтересовался возможностями GitHub Actions, но никогда не имел опыта реальной настройки build-систем. Примеры будут полезны как для прокачки собственного pet-проекта, так и для понимания, как настраивается CI/CD, если по работе нет связанных с этим задач.

Что будет рассмотрено:

Основные понятия для построения CI/CD на GitHub Actions.

Настроим работающий workflow который запускает Unit-тесты при создании pull request.

Добавим бейджики со статусом созданных workflow в репозиторий.

Настроим работающий workflow для сборки релизных артефактов APK и AAB.

Научимся безопасно подписывать ключом релизный APK.

GitHub Actions был выбран для примеров, потому что позволяет не углубляясь в инфраструктурные сложности с развёртыванием своего собственного CI-сервера буквально за день собрать работающий пайплайн для прогона тестов, подписи приложения и даже загрузки в Google Play. Кроме того, у GitHub Actions полная интеграция с GitHub, очень легко взаимодействовать с репозиторием. Для открытых репозиториев услуга бесплатная, для закрытых предусмотрены разные тарифные планы.

Но главное преимущество GitHub Actions состоит в возможности переиспользовать готовые блоки бизнес-логики (actions), причём не только свои собственные. На большинство самых распространённых задач уже скорее всего есть свой Action, который вы можете включить в свой пайплайн! Какие экшены уже написаны участниками сообщества, можно посмотреть на https://github.com/marketplace?type=actions

Примеры будут настраиваться на самом простом проекте с одной пустой Activity из шаблонов Android Studio и на новом пустом репозитории в GitHub.

Общие слова про Github Actions

Если кто-то представляет себе, как собирают автомобили на заводах, это неплохая иллюстрация к тому, чем вообще занимается CI/CD.

Пайплайн можно представить себе как конвейер на заводе, по которому непрерывно продвигается по стадиям подготовки релиза код.

На вход конвейера попадает коммит в репозиторий или пулл-реквест. Потом код попадает на участок сборки приложения, далее запускаются unit и UI-тесты. Если тесты прошли успешно, можно смело двигаться дальше по конвейеру, например, выложить в раздел релизов артефакт для истории версий.

Основные понятия

Вот так по блокам можно представить, как структурирован workflow в Github Actions.

Runner

Это развёрнутый в облаке от GitHub или self-hosted сервер с настроенным окружением и который может запускать workflow внутри себя.

Workflow

Это независимый процесс, автоматически запускаемый на GitHub Actions в отдельном контейнере по получению Event. Каждый workflow описывается отдельным YAML-файлом.

Состоит из более мелких структурных единиц исполнения — Jobs.

Job

Составная часть workflow, в свою очередь состоит из отдельных шагов Steps. Jobs могут быть настроены на параллельное и последовательное выполнение.

Step

Еще более мелкая единица исполнения скрипта, состоит из набора команд или действий.

Actions

Самая маленькая структурная единица исполнения скрипта workflow. Action может делать в принципе всё что угодно, например, проставлять теги с версией приложения в Git или отправлять собранный AAB в Google Play.

Можно писать как собственный Action, так и пользоваться готовыми. Action по сути выступает наравне с другими командами внутри Step.

Самые распространённые Action — это checkout на коммит и установка Java-окружения. По умолчанию, если специально не встать на нужный коммит, Job ничего не знает о проекте, из которого он запущен.

Пример ниже подготавливает окружение, а Uses указывает скрипту, что необходимо дождаться их окончания, прежде чем выполняться дальше.

Event

Внутренние или внешние события, которые запускают workflow. Commit, pull request, comment, tag — все эти события могут быть использованы в ваших скриптах как триггер для старта каких-то действий. Еще workflow может быть настроен на ручной запуск (https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/) и запуск по cron расписанию (https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#scheduled-events)

Hello, world!

Всё, что связано в GitHub Actions, располагается на вкладке Actions в репозитории.

При создании нового workflow GitHub пытается проанализировать содержимое репозитория и предлагает шаблон на выбор. На самые популярные сценарии сборки и деплоя можно найти заготовки.

Все workflow конфигурируются через файлы в формате YAML, это фактически стандарт для CI/CD-систем.

Чтобы GitHub Actions начала выполнять таски, необходимо положить их в определённым образом названную директорию в корне проекта github/workflows.

Добавлять и редактировать конфиги можно как в Android Studio, так и в самом GitHub на вкладке Actions. Так и поступим.

Сами конфиги в YAML можно называть как угодно, но лучше давать осмысленные имена для того, чтобы позднее самому понимать, что именно тут настроено.

GitHub сразу же подставляет самый простой скрипт, который делает checkout на новый коммит, выводит в консоль несколько строк и заканчивает работу. Что-то ещё проще придумать сложно, но даже в этом примере есть что посмотреть.

Сделать коммит с новым скриптом можно прямо из веб-интерфейса GitHub.

Но когда этот workflow будет отрабатывать? Ведь мы раньше упоминали, что в GitHub Actions все workflow запускаются не сами по себе, а только при получении того event’а, который прописан в самом yml-скрипте.

Тут видно, что наш тестовый скрипт будет выполняться для любых коммитов и пулл-реквестов в ветку main.

Стойте, так мы ведь только что сделали коммит с новым hello_world.yml, получается, он уже должен был сработать? Совершенно верно, можно прямо сейчас зайти в раздел actions и посмотреть результат работы скрипта.

Уже неплохо! Обычно после первого знакомства с новой технологией сразу хочется усложнить свой hello world и заставить его делать хоть что-то полезное, кроме вывода текста в консоль.

Запуск unit-тестов на каждый pull request в main

Первый YAML-скрипт мы создавали в веб-интерфейсе GitHub, теперь сделаем то же самое в Android Studio.

Чтобы увидеть директорию с YAML-файлами, нужно переключить режим просмотра на “Project” (если вдруг у вас был выбран режим “Android”).

Находим директорию workflows и создаём новый файл с типом YML. Назовём его, к примеру, run_unit_tests.yml.

Пока что всё, что мы хотим от скрипта, — это запускать unit-тесты на каждом pull request в ветку main. Можно скопировать целиком код из примера, всё должно работать. Если GitHub покажет, что в YAML ошибка, то проверить в первую очередь стоит правильность форматирования и количество отступов у блоков, так как формат чувствителен к этому.

actions/checkout@v2 и actions/setup-java@v1 подготавливают окружение для запуска тестов, первый выкачивает репозиторий и встаёт на нужный коммит, а второй устанавливает Java 8 — окружение. Это те самые Actions, которые даже упоминаются в названии, самые маленькие исполняемые единицы workflow. Можно рассматривать их как подключаемые к вашему workflow внешние библиотеки. Если интересно, что именно делают эти Actions, переходите по ссылкам https://github.com/actions/checkout и https://github.com/actions/setup-java

run: ./gradlew test запускает тесты с помощью gradle wrapper.

Запускать можно всё то же самое, что и в консоли, доступны все команды shell. Можно ещё написать свой собственный shell-скрипт и просто запустить его в этом месте, например, так: “run: ./run_unit_tests.sh”

Тут открывается простор для автоматизации всего что только можно. Если раньше вы никогда самостоятельно не писали shell-скрипты, рекомендую прочитать книгу “The Linux Command Line: a Complete introduction” от William Shotts, очень хорошее введение в shell-автоматизацию.

Готово! Создаем любой пулл-реквест в ветку main и смотрим во вкладке Actions, что получилось.

Я специально испортил один unit-тест, чтобы показать ещё одну базовую настройку вашего CI/CD-пайплайна — запрет на merge в ветку main c поломанными тестами. Всё логично: если ваш новый коммит что-то поломает в бизнес-логике приложения, то автоматика не даст сделать по ошибке merge. Или по крайней мере предупредит о проблеме.

Настраивается это очень просто: заходим в Settings репозитория, вводим в “Branch name pattern” паттерн для тех веток, для которых хотим создать новое правило безопасности. В нашем случае можно ввести “main”. Далее проставляем галочки в нужных условиях правила и сохраняем.

Всё готово, вы только что создали своё первое правило для merge в своем репозитории. Смотрим теперь, как поведёт себя автоматика с pull-request, в котором поломаны тесты.

Работает! При желании можно запретить merge с проблемами даже для администраторов, там же в настройках merge protection rule.

Если хочется прямо сейчас самостоятельно что-то настроить, то вот несложное задание. Gradle task test, который мы запускали, генерит небольшой отчет по результатам запуска unit-тестов, всё лежит в app/build/reports/tests/testDebugUnitTest/

Попробуйте самостоятельно добавить после шага Run unit tests ещё один шаг, который выкачивает отчет по тестированию.

На этом часть про запуск unit-тестов закончена, дальше настроим сборку и подпись релизного APK.

Задачу сформулируем так: подготавливать нам APK и AAB и подписывать ключом из keystore. Причём сборку мы будем запускать только на pull request в main из веток с именем, начинающимся с release/

Задача стала чуть сложнее, поэтому будем рассматривать ее по шагам.

Шаг 1. Собираем APK и AAB. Пока не подписываем

Вот эта строчка является проверкой имени ветки, из которой создается pull request, и, если условие выполняется, workflow продолжается. Мы ведь решили запускать сборку и подпись только для релизных веток.

Этот блок команд запускает, используя Gradle wrapper, тесты, а затем сборку APK и AAB. Обратите внимание, вертикальная черта позволяет запускать несколько shell-команд в одном блоке run.

Следующий шаг достанет после сборки APK и оставит его в виде артефакта в GItHub. Если этого не сделать, все временные файлы будут удалены после завершения workflow. Стоит обратить внимание, что APK остаётся неподписанным, мы просто не сконфигурировали пока ничего для этого. В таком виде APK его ещё нельзя выложить в Google Play, как настроить автоматическое подписание, будет рассказано дальше.

Подробнее про Action upload-artifact@v2 можно посмотреть тут. Основное, что может этот Action, — это выкачать файл по имени либо целиком директорию и упаковать в zip-архив.

Аналогичным образом достаем и AAB-файл.

Шаг 2. Подписываем APK

Сначала немного теории, как и зачем вообще подписывать APK.

Цифровая подпись необходима для того, чтобы Google Play мог идентифицировать разработчика и в дальнейшем только он мог обновлять приложение, это крайне важная вещь в процессе размещения проекта в магазине приложений.

В целях безопасности цифровая подпись хранится не в открытом виде, а в специальном хранилище типа key value — файле с расширением jks или keystore. Сам файл хранилища стоит держать в надёжном месте, это, можно сказать, паспорт вашего приложения.

Как создать keystore

Если вы уже выложили своё приложение в Google Play, то ключ у вас точно есть. Если же нет — ниже простая инструкция.

Вариантов два — создать через консоль или через IDE.

Консоль

my_app_keystore.keystore — это название самого хранилища, которое мы создаем.

app_sign_key — название ключа, по которому мы будем доставать наш секретный ключ.

10000 — время жизни ключа в днях (примерно 27 лет).

Вводим пароль на хранилище, пароль на ключ и потом по желанию метаданные о владельце. Всё, хранилище готово, можно пользоваться.

2) В Android Studio

В меню студии заходим в Build -> Generate Signed Bundle / APK.

Дальше Next -> Create New и вводим всё то же самое: пароли, имя хранилища и имя ключа в хранилище.

Чтобы собранный APK успешно подписать ключом из хранилища, необходимо этот самый ключ достать по имени (key alias), предварительно получив доступ через пароль к хранилищу (store password) и пароль непосредственно к ключу (key password). Это происходит в рамках специального Gradle task, всё будет далее автоматизировано.

И тут возникает два вопроса.

Где хранить пароли от хранилища, не в открытом же виде прописывать их в конфигах?

Как и куда выкладывать само хранилище ключей для открытого проекта?

Для хранения секретных данных, например, таких как идентификаторы приложения в Facebook, VK или Firebase, сервис GitHub предлагает механизм Secrets.

Особенность механизма хранения в том, что после сохранения ключа уже невозможно будет просто так зайти и посмотреть его. Только ввести новый, полностью удалить или использовать “как есть” в коде по имени. В логах секретные данные скрываются за звёздочками.

После добавления секретов к ним можно обращаться через специальный синтаксис прямо из YAML-скриптов. Например, вот так мы запишем EXAMPLE_API_KEY_1 в переменную окружения и затем в Gradle-скрипте, которому она понадобится, достанем её через System.getenv(‘EXAMPLE_API_KEY_1‘)

Отлично, часть проблемы решена, но куда положить само хранилище?

Можно в сам проект, конечно, но раз мы тут занимаемся автоматизацией процесса сборки и подписи, то как насчёт отдельного приватного репозитория чисто под хранилище? После настройки можно будет по шаблону подписывать все ваши приложения из этого хранилища.

Ничего кроме хранилища мы не собираемся помещать в новый приватный репозиторий. Мы будем клонировать его прямо в наш основной репозиторий в директорию app/keystore перед подписью APK-файла и доставать из него ключ с помощью паролей, который поместим в секцию Secrets в основном репозитории. Вот так будет выглядеть структура проекта на CI после клонирования репозитория с ключом в проект с основным проектом.

Звучит не очень сложно, смотрим, как такое настроить в GitHub Actions.

Создаем приватный репозиторий и помещаем туда только хранилище ключей.

Генерируем Personal access token для доступа к приватному репозиторию с хранилищем.

Делаем всё по этой инструкции и не забываем сразу же скопировать сгенерированный токен. Этот токен будет играть роль логина и пароля при клонировании репозитория с хранилищем. Важно не запутаться и генерировать токен именно в том аккаунте, где расположен наш приватный репозиторий.

Добавляем Personal access token из предыдущего шага в секреты основного проекта под любым именем, например KEYSTORE_ACCESS_TOKEN.

Добавляем все пароли и key_alias от хранилища.

Добавляем название аккаунта и имя приватного репозитория туда же в секреты основного проекта через слеш, что-то вроде “another-account/secret-repo”. Это понадобится нам дальше, когда будем клонировать репозиторий с ключом в YAML-скрипте.

Оформляем workflow для сборки APK и AAB в YAML-файле.

За основу был взят workflow, который был описан ранее. Запускается так же на pull request в main, только из веток, начинающихся на release/*. Вы можете поменять так, как вам удобно, это просто для иллюстрации возможностей.

Что тут добавилось? Во-первых, в начале workflow записываются переменные окружения, вот тут:

Далее последовательно делаем два checkout — сначала на коммит в созданном pull request (это было и раньше), потом делаем checkout приватного репозитория с хранилищем.

Тут уже есть особенности. Необходимо передать в checkout@v2 аргумент, в какой репозиторий стучаться (repository), токен для доступа к нему (token) и path. Path — это путь внутри директории с основным проектом, куда нужно сложить файлы. Мы хотим получить хранилище в app/keystore. В принципе, не обязательно именно такой путь, главное указать выбранный путь в Gradle, чтобы он понимал, где искать хранилище. Полную документацию по checkout@v2 можно почитать тут.

Дальше всё уже знакомое. Запускаем тесты и сборку релизной версии артефактов. На этом с workflow всё, дальше начинаем подготавливать build.gradle проекта.

Редактируем build.gradle

Идея заключается в том, что в заранее указанную директорию (app/keystore/) на CI автоматически добавится хранилище, а у себя локально мы можем без опаски хранить его в структуре проекта и даже положить туда файл с паролем в открытом виде. Это если нам хочется собирать и подписывать APK локально.

Главное при этом добавить в gitignore всё содержимое app/keystore, чтобы случайно секретная информация не утекла с очередным коммитом.

Чтобы Gradle понимал, где ему брать my_app_keystore в случае запуска assembleRelease локально и на CI, делаем нехитрую проверку. Сначала ищем keystore_config в директории keystore. Не нашли — делаем вывод, что нас запустили на CI и пароль следует брать не из keystore_config-файла, а из переменных окружения.

keystore_config — тут стандартный способ хранить в открытом виде пароли, внутри он состоит из пар key=value. Всё то же самое, что мы записывали в секреты на GitHub, но в открытом виде.

Само зашифрованное хранилище кладём рядом, в той же директории.

Если потребности подписывать APK локально нет или хочется вручную запускать процесс через “Generate Signed Bundle / APK”, выбирая каждый раз нужный keystore, то можно всё упростить и оставить только часть про System.getenv()

Тут самостоятельно примите решение, что вам подходит, безопасное хранение паролей — действительно важная история.

Пробуем запустить на CI

Отлично! То, что нам нужно, — готовый к релизу артефакт, собранный автоматически на GitHub Actions.

Запускаем локально.

В Android Studio переходим в терминал, запускаем.

После успешного завершения подписанный APK будет ждать нас в app/build/outputs/apk/release.

На этом со сборкой артефактов можно закончить, самые базовые кейсы рассмотрены.

Чтобы потренироваться с этим, предлагаю вам самостоятельно настроить подпись для debug-сборок.

И еще одно самостоятельное задание для заинтересовавшихся: чтобы сделать проект еще красивее, по проставлению в git tag версии приложения (например, v1.0.0) собирать APK, подписывать и складывать в разделе релизов прямо в GitHub репозитории с правильным названием, включающим версию из tag.

Подсказка — удобно использовать https://github.com/actions/create-release, там в описании есть похожий на нашу задачу workflow.

Выводим на README.MD статус выполнения workflow

Здорово смотрятся бейджи со статусом прохождения этапов CI на главной странице репозитория. Наверняка вы много раз видели похожие бейджики с процентом покрытия тестами кода, статусом сборки и так далее. Давайте прямо сейчас сделаем такие для статуса прохождения unit-тестов, для этого у нас уже всё есть.

Итак, у нас уже есть несколько workflow. Документация очень подробная и с примерами.

Открываем README.md и пишем что-то вроде этого, подставляя своё реальное имя на GitHub, название текущего репозитория и имя workflow, для которого хочется иметь бейджик.

Сохраняем и смотрим результат.

По-моему, круто всего для двух минут настройки. Теперь всегда будет видно текущий статус прогона тестов. А ещё можно будет добавить статус сборки APK для релизных веток, что-нибудь от статического анализатора кода вроде Sonarcube, в общем, всё, что пожелаете.

На этом первая часть рассказа про GitHub Actions заканчивается. За короткое время мы смогли настроить очень неплохую автоматизацию для проекта.

В следующей части продолжим тему тестирования и посмотрим как настроить запуск UI тестов в Firebase Test Lab. Не пропустите, будет интересно.

Источник