在 Android Studio 中使用 Gradle 管理 Google Maps API 密钥

Posted 2023-04-18

【中文标题】在 Android Studio 中使用 Gradle 管理 Google Maps API 密钥

【英文标题】：Manage Google Maps API Key with Gradle in Android Studio

【发布时间】：2021-11-01 17:14:40

【问题描述】：

我知道 Gradle 功能强大，我想管理用于开发/生产 Google 地图的 API 密钥

目前我总是需要手动注释一行并取消注释另一行才能使其正常工作。有没有办法通过一些自定义发布配置在 Gradle 中自动完成？

<!-- 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]" />
-->

【问题讨论】：

伙计正是我需要的，好问题。

【参考方案1】：

由于您使用的是 gradle，您可以执行以下操作：

build.gradle

android 
  .. .. ...
    buildTypes 
       debug 
          resValue "string", "google_maps_api_key", "[YOUR DEV KEY]"
       
       release 
           resValue "string", "google_maps_api_key", "[YOUR PROD KEY]"
       
    
  

在你的 AndroidManifest.xml

<meta-data
            android:name="com.google.android.maps.v2.API_KEY"
            android:value="@string/google_maps_api_key"/>

这样你只有一个 AndroidManifest.xml 并且你根据你的构建类型设置值。希望这会有所帮助。

【讨论】：

这个解决方案在最新的 Android Studio 版本（1.1 Beta 2）上运行起来就像一个魅力！感谢分享。

我最终为我的各种产品风格添加了 resValue，效果很好。

这样存放安全吗？

@GokhanArik，是的，这样存储它是安全的。

@GokhanArik 让所有有权访问代码的人都可以使用您的 api 密钥是安全的，不。关于它是否会起作用并且什么都不会搞砸，是的，是安全的。

【参考方案2】：

您可以使用清单占位符功能实现此目的：http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger#TOC-Placeholder-support

在 build.gradle 文件中：

buildTypes 
    debug 
        manifestPlaceholders = [ google_map_key:"your_dev_key"]
    
    release 
        manifestPlaceholders = [ google_map_key:"prod_key"]
    

然后在清单中：

<meta-data
    android:name="com.google.android.maps.v2.API_KEY"
    android:value="$google_map_key"/>

这对于不同风格的不同键来说是准确的，这是比使用字符串资源更清洁的解决方案。

附：另一方面，我最好考虑从后端获取 api 密钥，不要在客户端对它们进行硬编码。这是更安全、更灵活的方法。

【讨论】：

我们如何在活动（Java 文件）中访问这个google_map_key？

试试这个：ApplicationInfo ai = getPackageManager().getApplicationInfo(activity.getPackageName(), PackageManager.GET_META_DATA); String myApiKey = ai.metaData.getString("com.google.android.maps.v2.API_KEY");

对我来说，这仅在 android.defaultConfig 中定义 manifestPlaceholders 时有效，如 docu 中所述，出于某些原因。

附言。如果您从后端获取 api 密钥，您是否仍然需要在某处硬编码您的后端 url，以及调用该 api 的密钥？现在您需要将新凭据存储在某处。

@babyishTank 视情况而定。一个不错的选择可能是让端点返回需要授权的短期机密（不适合每个应用程序）。并非每项服务都支持短暂的秘密，但 IMO 最好的选择是防止有人滥用您的付费服务帐户。但绝对从现在开始，我建议永远不要将任何秘密硬编码到应用程序中，如果需要，只需从后端检索它。

【参考方案3】：

在 Android Studio（检查版本 0.8.11）中，您可以将 Google Maps Activity（New->Google->Google Maps Activity）添加到您的项目中，Android Studio 将为您生成必要的文件，您只需插入您的键。还会生成指令。在 debug/res/values/ 和 release/res/values 文件夹中查找 google_maps_api.xml 文件。

【讨论】：

是的，这适用于较新版本的 Android 并使用 Android Studio： res > values > google_map_api.xml 和

【参考方案4】：

在 Android Studio 中，存在构建类型和风格的概念，您可以使用它们来获得所需的内容。构建类型是功能相同但调试代码不同的应用程序的不同版本。默认情况下，所有 Android Gradle 项目都有调试和发布构建类型。

风味是功能不同的应用版本；例如，您可以免费和付费。默认情况下，您的 Android Gradle 项目没有任何风格，但您可以添加它们。

在您进行构建时，构建类型和风格会组合在一起（形成所谓的变体）；在此示例中，您可以有 freeDebug、freeRelease、paidDebug 和paidRelease 构建。

构建系统可让您轻松覆盖每种类型/风味/变体中的许多内容；您可以做的其中一件事是覆盖部分 AndroidManifest.xml 文件。构建系统在构建特定变体时将清单的不同合格位合并到一个主清单中。

有了这些背景，在您的情况下，您可能希望在应用的调试版本与发布版本中使用不同的 API 密钥。调试版本是您将在日常开发、调试和测试中使用的版本，而发布版本是您要部署给用户的版本。

为此，不要将 Google Maps API 密钥放入主应用的 AndroidManifest.xml 文件中的src/main；相反，添加两个新文件夹 src/debug 和 src/release 并在其中添加 stub AndroidManifest.xml 文件。不要在这些新清单中包含完整信息，而仅包含该特定变体所需的独特信息。您的源文件将如下所示：

您的src/debug/AndroidManifest.xml 文件将包含以下内容：

<?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>

src/release/AndroidManifest.xml 会有这个：

<?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>

重申一下，不要将任何 API 密钥放在 src/main/AndroidManifest.xml 文件中。

如果出于某种原因您不想使用构建类型来区分您可以设置开发和产品风格并以这种方式进行拆分；清单覆盖的工作方式相同。

【讨论】：

感谢您的所有解释。我赞成您对出色解释的回答，但我发现 Okas 解决方案更优雅，因为它避免了清单的重复并将密钥放在 XML 资源字符串中。我知道原理和你的解释一样。