Gérer Google Maps API Key avec Gradle dans Android Studio

Je sais Gradle est puissant et je voudrais gérer les clés API pour le développement/produciton de Google Maps

Actuellement j'ai toujours besoin d'manuellement commentaire d'une ligne et supprimez les marques de l'autre pour le faire fonctionner. Est-il un moyen de le faire automatiquement dans Gradle avec quelques personnalisé configuration de version ?

<!-- MapView v2 API -->
<uses-library android:name="com.google.android.maps" />
<meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="[MY_DEV_KEY]" />
<!-- PROD
<meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="[MY_PROD_KEY]" />
-->

Mec exactement ce dont j'avais besoin, bonne question.

InformationsquelleAutor Hrk | 2014-09-30

107

Puisque vous êtes à l'aide de gradle vous pouvez effectuer les opérations suivantes:

construire.gradle
```
android {
  .. .. ...
    buildTypes {
       debug {
          resValue "string", "google_maps_api_key", "[YOUR DEV KEY]"
       }
       release {
           resValue "string", "google_maps_api_key", "[YOUR PROD KEY]"
       }
    }
  }
```
Et dans votre AndroidManifest.xml
```
<meta-data
            android:name="com.google.android.maps.v2.API_KEY"
            android:value="@string/google_maps_api_key"/>
```
De cette façon, vous n'avez qu'une AndroidManifest.xml et vous le mettre en valeur en fonction du type de build. Espérons que cette aide.
- Cette solution fonctionne comme un charme avec le dernier Android Studio version (1.1 Beta 2)! Merci pour le partage.
- J'ai fini par l'ajout de resValue pour chacun de mes différentes saveurs et il a très bien fonctionné.
- Est-il sécuritaire de magasin comme ça?
- oui c'est sûr pour stocker des comme ça.
- coffre-fort en termes de faire de votre clef api disponible pour tout le monde qui a accès au code, il n'. Coffre-fort quant à savoir s'il serait de travailler et vous ne pourrez rien gâcher, oui.
- J'ai besoin de récupérer les clés API de gradle.propriétés en fonction de différents buildType.. aucune solution en ce qui concerne qui?
InformationsquelleAutor bond
24

Vous pouvez réaliser cela avec le manifeste de l'espace réservé fonctionnalité: http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger#TOC-Placeholder-support

dans la construction.gradle fichier:
```
buildTypes {
    debug {
        manifestPlaceholders = [ google_map_key:"your_dev_key"]
    }
    release {
        manifestPlaceholders = [ google_map_key:"prod_key"]
    }
}
```
et puis dans le manifeste:
```
<meta-data
    android:name="com.google.android.maps.v2.API_KEY"
    android:value="${google_map_key}"/>
```
C'est la chose exacte pour des clés différentes pour les différentes saveurs et c'est plus propre solution que d'utiliser des ressources de chaîne.

InformationsquelleAutor IlyaEremin
13

Dans Android Studio (vérifié avec la version 0.8.11) vous pouvez ajouter Google Maps Activité (Nouveau->Google->Google Maps Activité) à votre projet et Android studio génère les fichiers nécessaires pour vous, vous n'avez qu'à insérer vos clés. Il y a aussi des instructions générées. Recherchez google_maps_api.xml dans vos fichiers de debug/res/values/et publication/res/valeurs dossiers.
- Oui, cela s'applique à des versions plus récentes d'Android et Android Studio: res > valeur > google_map_api.xml et un <string nom="google_maps_key" ... Et votre mise en page fichier xml contient un fragment en elle.
InformationsquelleAutor Okas
11

Dans Android Studio, il y a le concept de construire des types et de saveurs, et vous pouvez les utiliser pour obtenir ce dont vous avez besoin. Les types de builds sont les différentes versions de l'application qui sont fonctionnellement identiques, mais peuvent différer dans le code de débogage. Par défaut, tous les Android Gradle projets ont debug et release construire des types.

Saveurs sont des versions de votre application qui sont fonctionnellement différentes, vous pouvez avoir gratuit et payant, par exemple. Par défaut, votre Android Gradle, les projets n'ont pas toutes les saveurs, mais vous pouvez en ajouter.

Construire des types et de saveurs sont combinés (dans ce qu'on appelle un variante) lorsque vous faites une génération; dans cet exemple, vous pouvez avoir freeDebug, freeRelease, paidDebug, et paidRelease construit.

Le système de construction permet de remplacer un certain nombre de choses dans chaque type/saveur/variante, l'une des choses que vous pouvez faire est de remplacer les pièces de l'AndroidManifest.xml fichier. Le système de construction fusionne les différents admissibles bits de se manifeste dans un master manifeste lorsqu'il construit une variante particulière.

Avec qui fond dans la main, dans votre cas, vous pouvez avoir une autre clé API dans la version de débogage de votre application contre la version. La version de débogage est ce que vous allez utiliser dans votre journée-à-jour de développement, le débogage et de test, et la version est ce que vous souhaitez déployer pour les utilisateurs.

Pour ce faire, ne pas mettez l'API Google Maps clé dans l'application principale de l'AndroidManifest.xml fichier dans src/main; au lieu de cela, ajouter deux nouveaux dossiers, src/debug et src/release et ajouter tampon AndroidManifest.xml des fichiers. Ne pas inclure des renseignements complets dans les nouveaux manifestes, mais seulement ce qui est unique au sujet de ce qui est nécessaire pour cette variante. Vos fichiers source ressemblera à ceci:

Votre src/debug/AndroidManifest.xml fichier contiendra ceci:
```
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="[MY_DEV_KEY]" />
</manifest>
```
et src/release/AndroidManifest.xml aurez ceci:
```
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="[MY_PROD_KEY]" />
</manifest>
```
De réitérer, ne mettez pas de clé API dans le src/main/AndroidManifest.xml fichier.

Si pour quelque raison vous ne souhaitez pas utiliser les types de builds pour vous différencier pourraient mettre en place des dev et prod saveurs et de le diviser de cette façon au lieu; le manifeste primordial fonctionne de la même manière.
- Merci pour toutes les explications. J'ai upvote votre réponse pour la grande explication, mais j'ai trouvé le Okas solution plus élégante car elle permet d'éviter la duplication de manifester et de mettre la clé dans un fichier XML chaîne de ressource. Je sais que le principe est le même que celui de votre explication.
InformationsquelleAutor Scott Barta

Vous devez vous connecter pour publier un commentaire.