Add the API key to you app

Restrict the API key

We strongly recommend that you restrict your API key. Restrictions provide added security and help
ensure only authorized requests are made with your API key. There are two restrictions. You should
set both:

Application restriction: Limits usage of the API key to a specific web site
(HTTP referrers), web server (IP addresses), or mobile app (Android apps or iOS apps). You can
select only one restriction from this category (see GMP APIs by Platform).

API restriction: Limits usage of the API key to one or more APIs or SDKs.
Requests to an API or SDK associated with the API key will be processed.
Requests to an API or SDK not associated with the API key will fail. (The API or SDK must be
enabled and must support the
application restriction.)

Click Select APIs and select Places API.
(If the Places API is not listed, you need to enable it.)

Click SAVE.

Find your app's certificate information

Note:
All Android apps are signed with a digital certificate for which you
hold the private key. Refer to the Android guide to
signing
your applications for more information about digital
certificates.

Android-restricted API keys are linked to specific certificate/package pairs. You only
need one key for each certificate, no matter how many users you have for
the app.

The API key is based on a short form of your app's digital certificate,
known as its SHA-1 fingerprint. To display the SHA-1
fingerprint for your certificate, first ensure that you are using the right
certificate. You may have two certificates:

A debug certificate: The Android SDK tools generate
this certificate automatically when you do a debug build. Only use this
certificate with apps that you're testing.
Do not attempt to publish an app that's signed with a debug certificate.
The debug certificate is described in more detail in
Signing
in Debug Mode in the Android Developer Documentation.

A release certificate: The Android SDK tools generate
this certificate when you do a release build. You can also generate this
certificate using the keytool program. Use this certificate when
you are ready to release your app to the world.

Using Gradle

Gradle makes it very easy to get your app's signing info.
Simply run ./gradlew signingReport.

Manually

Follow the steps below to display a certificate's SHA-1 fingerprint using
the keytool program with the -v parameter. For more
information about Keytool, see the
Oracle documentation.

Debug certificate

Displaying the debug certificate fingerprint

Locate your debug keystore file. The file name is
debug.keystore, and is created the first time you build your
project. By default, it is stored in the same directory as your Android
Virtual Device (AVD) files:

Displaying the release certificate fingerprint

Locate your release certificate keystore file. There is no default
location or name for the release keystore. If you don't specify one when
you build your app for release, the build will leave your
.apk unsigned, and you'll have to sign it before you can
publish it. For the release certificate, you also need the certificate's
alias and the passwords for the keystore and the certificate. You can list
the aliases for all the keys in a keystore by entering:

keytool -list -keystore your_keystore_name

Replace your_keystore_name with the fully-qualified
path and name of the keystore, including the .keystore
extension. You'll be prompted for the keystore's password. Then
keytool displays all the aliases in the keystore.

Enter the following at a terminal or command prompt:

keytool -list -v -keystore your_keystore_name -alias your_alias_name

Replace your_keystore_name with the fully-qualified
path and name of the keystore, including the .keystore
extension. Replace your_alias_name with the alias that
you assigned to the certificate when you created it.

The line that begins SHA1 contains the certificate's SHA-1
fingerprint. The fingerprint is the sequence of 20 two-digit hexadecimal
numbers separated by colons.

Caution: To protect your keystore and
key, don't enter the storepass or keypass
arguments on the command line unless you're confident of your computer's
security. For example, on a public computer, someone could look at your
terminal window history or list of running processes, get the password,
and then have write access to your signing certificate. This would allow
that person to modify or replace your app with their own.