Щоб вирішити це для своєї ситуації, я створив три проекти Firebase, кожен з тим самим проектом Android (тобто такий же, applicationIdне використовуючи applicationIdSuffixзапропоновані іншими). Це призвело до появи трьох файлів google-services.json, які я зберігав на сервері постійної інтеграції (CI) як змінні спеціального середовища . Для кожного етапу збірки (dev / staging / prod) я використовував відповідний файл google-services.json.
Для проекту Firebase, пов’язаного з dev, у свій проект Android я додав відбиток сертифікату відладки SHA. Але для постановки і продажу я просто підписав CI APK.
Ось знімок, .gitlab-ci.ymlякий працював для цієї установки:
# This is a Gitlab Continuous Integration (CI) Pipeline definition
# Environment variables:
# - variables prefixed CI_ are Gitlab predefined environment variables (https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)
# - variables prefixed GNDR_CI are Gitlab custom environment variables (https://docs.gitlab.com/ee/ci/variables/#creating-a-custom-environment-variable)
#
# We have three Firebase projects (dev, staging, prod) where the same package name is used across all of them but the
# debug signing certificate is only provided for the dev one (later if there are other developers, they can have their
# own Firebase project that's equivalent to the dev one). The staging and prod Firebase projects use real certificate
# signing so we don't need to enter a Debug signing certificate for them. We don't check the google-services.json into
# the repository. Instead it's provided at build time either on the developer's machine or by the Gitlab CI server
# which injects it via custom environment variables. That way the google-services.json can reside in the default
# location, the projects's app directory. The .gitlab-ci.yml is configured to copy the dev, staging, and prod equivalents
# of the google-servies.json file into that default location.
#
# References:
# https://firebase.googleblog.com/2016/08/organizing-your-firebase-enabled-android-app-builds.html
# /programming/57129588/how-to-setup-firebase-for-multi-stage-release
stages:
- stg_build_dev
- stg_build_staging
- stg_build_prod
jb_build_dev:
stage: stg_build_dev
image: jangrewe/gitlab-ci-android
cache:
key: ${CI_PROJECT_ID}-android
paths:
- .gradle/
script:
- cp ${GNDR_CI_GOOGLE_SERVICES_JSON_DEV_FILE} app/google-services.json
- ./gradlew :app:assembleDebug
artifacts:
paths:
- app/build/outputs/apk/
jb_build_staging:
stage: stg_build_staging
image: jangrewe/gitlab-ci-android
cache:
key: ${CI_PROJECT_ID}-android
paths:
- .gradle/
dependencies: []
script:
- cp ${GNDR_CI_GOOGLE_SERVICES_JSON_STAGING_FILE} app/google-services.json
- ./gradlew :app:assembleDebug
artifacts:
paths:
- app/build/outputs/apk/
jb_build_prod:
stage: stg_build_prod
image: jangrewe/gitlab-ci-android
cache:
key: ${CI_PROJECT_ID}-android
paths:
- .gradle/
dependencies: []
script:
- cp ${GNDR_CI_GOOGLE_SERVICES_JSON_PROD_FILE} app/google-services.json
# GNDR_CI_KEYSTORE_FILE_BASE64_ENCODED created on Mac via:
# base64 --input ~/Desktop/gendr.keystore --output ~/Desktop/keystore_base64_encoded.txt
# Then the contents of keystore_base64_encoded.txt were copied and pasted as a Gitlab custom environment variable
# For more info see http://android.jlelse.eu/android-gitlab-ci-cd-sign-deploy-3ad66a8f24bf
- cat ${GNDR_CI_KEYSTORE_FILE_BASE64_ENCODED} | base64 --decode > gendr.keystore
- ./gradlew :app:assembleRelease
-Pandroid.injected.signing.store.file=$(pwd)/gendr.keystore
-Pandroid.injected.signing.store.password=${GNDR_CI_KEYSTORE_PASSWORD}
-Pandroid.injected.signing.key.alias=${GNDR_CI_KEY_ALIAS}
-Pandroid.injected.signing.key.password=${GNDR_CI_KEY_PASSWORD}
artifacts:
paths:
- app/build/outputs/apk/
Я задоволений цим рішенням, оскільки він не покладається на трюки build.gradle, які, на мою думку, занадто непрозорі і тому важко підтримувати. Наприклад, коли я спробував підходи з використанням applicationIdSuffixі різних buildTypes, я виявив, що не можу отримати інструментальні тести для запуску або навіть компіляцію, коли я намагався переключити типи збірки за допомогою testBuildType. Android ніби надає особливі властивості, debug buildTypeякі я не міг перевірити, щоб зрозуміти.
Щоправда, сценарії CI, хоча на моєму досвіді, досить прозорі і прості в обслуговуванні. Справді, підхід, який я описав, спрацював: Коли я запускав кожен з APK-файлів, створених CI, на емуляторі, крок консолі Firebase "Запустити додаток для перевірки встановлення" пішов з
Перевірка, чи додаток спілкувався з нашими серверами. Можливо, вам доведеться видалити та перевстановити додаток.
до:
Вітаємо, Ви успішно додали Firebase у свій додаток!
для всіх трьох додатків, коли я запускав їх по одному в емуляторі.
