Aby rozwiązać ten problem w mojej sytuacji, stworzyłem trzy projekty Firebase, każdy z tym samym projektem na Androida (tj. Taki sam applicationIdbez korzystania z applicationIdSuffixsugerowanych przez innych). W rezultacie powstały trzy pliki google-services.json, które zapisałem na moim serwerze Continuous Integration (CI) jako niestandardowe zmienne środowiskowe . Na każdym etapie kompilacji (dev / staging / prod) użyłem odpowiedniego pliku google-services.json.
W przypadku projektu Firebase skojarzonego z dev, w jego projekcie na Androida dodałem odcisk cyfrowy certyfikatu debugowania SHA. Ale do inscenizacji i prod mam po prostu podpisać plik APK.
Oto uproszczona wersja, .gitlab-ci.ymlktóra działała w tej konfiguracji:
# 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/
Jestem zadowolony z tego rozwiązania, ponieważ nie opiera się na sztuczkach build.gradle, które moim zdaniem są zbyt nieprzejrzyste i przez to trudne do utrzymania. Na przykład, kiedy próbowałem podejść przy użyciu applicationIdSuffixi różnych metod buildType, stwierdziłem, że nie mogę uruchomić testów instrumentalnych ani nawet skompilować, gdy próbowałem zmienić typy kompilacji za pomocą testBuildType. Android wydawał się nadawać specjalne właściwości, debug buildTypektórych nie mogłem zrozumieć.
Praktycznie, z mojego doświadczenia wynika, że skrawki CI są dość przejrzyste i łatwe w utrzymaniu. Rzeczywiście, podejście, które opisałem, zadziałało: kiedy uruchomiłem każdy z pakietów APK wygenerowanych przez CI na emulatorze, krok „Uruchom aplikację, aby zweryfikować instalację” konsoli Firebase wyszedł z
Sprawdzanie, czy aplikacja komunikowała się z naszymi serwerami. Może być konieczne odinstalowanie i ponowne zainstalowanie aplikacji.
do:
Gratulacje, pomyślnie dodałeś Firebase do swojej aplikacji!
dla wszystkich trzech aplikacji, ponieważ uruchamiałem je pojedynczo w emulatorze.
