Integrating LaunchKey with Android

This document walks you through integrating LaunchKey with Android apps.

Setting Up the LaunchKey Service

Before integrating LaunchKey with your app, an administrator must complete the following steps:

  1. From an Android device, launch the Google Play store.
  2. Download and install LaunchKey.
  3. Run the LaunchKey app.
  4. On the Device Setup page, do one of the following:
    1. If you alreacy have an account, choose I already have an account. On the Existing User Setup page, enter the username associated with the account, and enter a unique name for the device.
    2. If you don't already have an account, choose I'm a New LaunchKey User. On the New Account Setup page, Enter a unique user-name. Note this user name as you will need it when configuring the service in the LaunchKey Dashboard. On the Device Name page, enter a nickname for the device.
  1. On the Linking Method page, choose a contact method for linking the device, such as SMS or Email & SMS. Enter the contact information and click Done.
  2. Based on the linking method you chose, you will receive a text message or email with further instructions for completing the device configuration process. Respond as instructed.
  3. Now that the device is configured, you must associate it with a service in the LaunchKey Dashboard. From a browser, open the Dashboard at https://dashboard.launchkey.com/login.
  4. To log in, enter the username that you entered into the app when you linked the device.
  5. On the device, authorize the login.
  6. Now that you are in the Dashboard, click the left navigation button and select Organizations. The All Organizations page appears.
  7. Click the Create New Organization button. The Create New Organization screen appears.
  8. Enter a name for the organization, provide the your name and email address (or name and email address of an admin user). Complete the Create New Organization Screen.
  9. The user whose email you entered will receive a confirmation email. Click the confirmation email to complete creation of the organization.
  10. Back in the Dashboard, open the organization you created. Expand the menu button on the left of the screen and select Organizations, then click the organization.
  11. From within the organization, select the White Label tab.
  12. Click the New White Label Group button to create a new directory. Enter the username for the account that you created on the device, early in this procedure.
  13. Directory details appear. From here, on the General tab, you can see a Mobile SDK Keys list. Capture the Mobile SDK Key. You will need it later when integrating the LaunchKey SDK into your app.
  14. Also on the General tab, under Services, click the NEW APP button. The Create New Service screen appears.
  15. Enter a name and description for the service. Optionally choose an avatar file, read and accept the Terms of Service and click the Create Service button.

You are now ready to integrate the LaunchKey SDK into your mobile apps.

Integrating the Android SDK into Your App

Integration Overview

At a high level, integrating the LaunchKey SDK for Android into your app includes the following steps:

  1. Adding the SDK as a dependency in Android Studio.
  2. Provide credentials for the LaunchKey directory.
  3. Run the calls to initialize the SDK and interact with its core features.

Integration Steps

Follow these detailed steps to integrate the LaunchKey SDK for Android into your app:

  1. Download the SDK from https://github.com/iovation/launchkey-android-whitelabel-sdk

  2. In Android Studio, add the LaunchKey SDK to your project as a dependency.

  3. To initialize the SDK, build an AuthenticatorConfig object via AuthenticatorConfig.Build and pass it to the singleton instance of AuthenticatorManager. For example:

    //This key can be obtained in a one-time operation just to link the device.
    String mobileSdkKey = ...
    
    //Build AuthenticatorConfig.
    AuthenticatorConfig config = new AuthenticatorConfig.Builder(context, mobileSdkKey).build();
    
    //Get singleton instance of AuthenticatorManager and initialize with AuthenticatorConfig object.
    AuthenticatorManager manager = AuthenticatorManager.getInstance();
    manager.initialize(config);
    
    //Later verify whether the manager has been initialized.
    manager.isInitialized();
    
  4. To enable users to link their devices, specify a linking mechanism. You can enable either QR code scanning or the ability to manually enter their linking code. To do this, use the following code:

    AuthenticatorManager manager = AuthenticatorManager.getInstance();
    //To enable end-users to scan a QR code in order to link their devices:
    manager.startLinkingActivity(this, AuthenticatorManager.LINKING_METHOD_SCAN);
    //Or, to enable end-users to enter their linking codes manually:
    manager.startLinkingActivity(this, AuthenticatorManager.LINKING_METHOD_MANUAL);
    
    //After linking the device, determine the resulting device status:
    if (manager.isDeviceLinked()) {
    //And direct the user to the next step. ake user to a different Activity...
    } else {
    //Or, if linking fails, direct the user to try again.
    }
    
  5. End-users can choose their own security factors. We recommend requiring end-users to choose a minimum number of factors by calling startSecurityActivity() in the AuthenticatorManager instance. For example:

    AuthenticatorManager manager = AuthenticatorManager.getInstance();
    manager.startSecurityActivity(context);
    
  6. You must embed a fragment from the SDK in the authentication activities that will require users to approve or deny pending authentication requqests. To embed this fragment:

    1. You can add the fragment via XML or programmatically. To add it via XML, use the <fragment> tag and set its canonical class via the name property. You can also set other attributes as needed such as id, layout_width, and layout height. For example:

      <Layout
      ...
      >
      ...
      <fragment
          android:id="@+id/authrequestfragment"
          android:name="com.launchkey.android.whitelabel.sdk.ui.AuthRequestFragment"
          android:layout_width="..."
          android:layout_height="..."
      />
      ...
      </Layout>
      
    2. To add it programmatically, instantiate it and make sure that your FragmentManager adds it to the correct container layout. For example:

      //Store the ID of the fragment container
      private static final int FRAGMENT_CONTAINER_ID = R.id.activity_fragment_container;
      //Instantiate a new Fragment via its class (or using Fragment#instantiate(...))
      AuthRequestFragment authRequestFragment = new AuthRequestFragment();
      ...
      //Set Fragment via FragmentManager (or SupportFragmentManager if using AppCompat)
      getFragmentManager()
      .beginTransaction()
      .add(FRAGMENT_CONTAINER_ID, authRequestFragment)
      .commit();
      
    3. Optionally display the Toolbar part of the Fragment. This allows end-users to either deny a pending authentication request or review more information. By default this toolbar is hidden. Additional options include providing custom toolbars or overriding the default XML to display the default toolbar.

      To programmatically display the toolbar, see the following example:

      AuthRequestFragment authRequestFragment = new AuthRequestFragment();
      authRequestFragment.setToolbarVisible(true);
      
    4. When end-users return to the authentication activity, they should see any pending authentication requests. To implement this, check back with the LaunchKey platform for any outstanding requests. The following example also provides the option to manually check for oustanding requests:

      AuthRequestFragment authRequestFragment = new AuthRequestFragment();
      ...
      //When calling onResume() or your own refresh option, use with the following method:
      authRequestFragment.checkForPending();
      
  7. Optionally, provide a method using AuthenticatorManager to enable either the end-user or the app itself to unlink the device. For example:

    AuthenticatorManager manager = AuthenticatorManager.getInstance();
    ...
    SimpleOperationCallback unlinkCallback = new SimpleOperationCallback() {
    
            @Override
            public void onResult(boolean successful, BaseError error, Object o) {
    
                if (successful) {
                    //Inform the end-user that the device has been successfully unlinked
                } else {
                    // There was a problem notifying the LaunchKey Platform even
                    // though the unlinking operation is unlikely to fail.
                    // More details on the error are given with the BaseError object returned if
                    unlinking isn't successful.
                }
            }
        };
    manager.unlinkCurrentDevice(unlinkCallback);
    

This completes the core integration. Continue on to the next section for advanced integration options.

Advanced Integration Options

Now that the LaunchKey SDK for Android is integrated and the basics are working, let's move on to more advanced integration options. We'll start by reviewing the technical components that make up advanced LaunchKey integration.

Activation Delay (v3.0.4 and up)

The Authenticator SDK allows you to set an activation delay for passive security factors, such as geo-fences or Bluetooth proximity devices. This is the time it takes for the SDK to add or remove a passive factor. The delay also applies when an end-user toggles the verification setting for a security factor, which changes how the factor is verified during auth requests, for example only when required, or always.

You can set the delay for a range of time between 0 seconds to 24 hours. Provide the value in seconds, for example set it to 600 (or to a simple equation such as 10 * 60) for a delay of 10 minutes.

For example:

final int geofencingDelaySeconds = 20 * 60;     //20 minutes
final int proximityDelaySeconds = 10 * 60;      //10 minutes

manager.initialize(
        new AuthenticatorConfig.Builder(context, mobileSdkKey)
                .activationDelayGeofencing(geofencingDelaySeconds)
                .activationDelayProximity(proximityDelaySeconds)
                ...
                .build());

Warning

Setting the activation delay to 0 can potentially allow anyone to bypass passive security factors. They can do this by adding new, unintended passive factors and setting the verification toggle to only verify when required. If the user then immediately attempts to authenticate, the new passive factor will not be verified. For this reason, we strongly suggest setting the value to a minimum of ten minutes / 600 seconds.

Default Views

The LaunchKey SDK provides default views the enable end-users to interact with their linked devices and active sessions. To use the default views, embed the following fragments either via XML or programmatically, as you did with AuthRequestFragment:

  • com.launchkey.android.authenticator.sdk.ui.fragment.DevicesFragment
  • com.launchkey.android.authenticator.sdk.ui.fragment.SessionsFragment

Managers

The LaunchKey SDK provides managers that make it possible to replace the default views with custom views of the available data, with hooks to specific action associated with each item.

The following managers are available:

  • AuthenticatorManager: The primary manager that must be initialized to enable the end-user to interact with LaunchKey platform. It provides access to device functions such as initialization, linking and unlinking, and security factors.
  • AuthRequestManager: This manager handles authentication requests. It can return the AuthRequest object that contains all the information necessary to display to an end-user about a request. It can also enable the app itself to deny a pending request programmatically. End-user authentication is managed directly by the AuthRequestFragment.
  • DeviceManager: This manager handles all linked devices for the current user. It enables the app to unlink any currently linked devices. This includes the current device, which is equivalent to calling AuthenticatorManager.unlinkCurrentDevice(...).
  • SessionManager: This manager handles all active sessions that the end-user authorized via AuthRequestFragment. It also enables the mobile app to end a particular session, or all of the sessions.

Events and Notifications

The managers provided by the LaunchKey SDK notify recipients regarding events for which they are responsible. The registerForEvent(...) and unregisterForEvent(...) methods enable registration for the events.

Event callbacks return the following properties as part of the onEventResult(...) method:

  • successful (boolean): The result of the request.
  • error: Error that resulted from the request. If successful is true, the error object is null.
  • result: If the request is successful, this is the result object. For example, for DeviceLinkedEventCallback, when the current device has just been linked, this is a device object that contains all of the device properties.

The following table contains all of the events broadcast by each manager.

Event class Description
AuthenticatorManager accepts event callbacks extending AuthenticatorManager.BaseManagerEventCallback
DeviceLinkedEventCallback Event callback when the current device is linked. The result is a Device object representing the device and its basic properties.
DeviceUnlinkedEventCallback Event callback when the current device is unlinked. There is no result object.
AuthRequestManager accepts event callbacks extending AuthRequestManager.BaseManagerEventCallback
GetAuthRequestEventCallback Event callback when the LaunchKey platform is queried about any pending auth requests. The result is of the AuthRequest type.
AuthRequestResponseEventCallback Event callback when there is a response to a pending auth request. The result is a boolean value set to true if the request is authorized by the user.
DeviceManager accepts event callbacks extending DeviceManager.BaseManagerEventCallback
GetDevicesEventCallback Event callback when the list of all linked devices is fetched from the LaunchKey platform. The result is of the List<Device> type.
UnlinkDeviceEventCallback Event callback when a device other than the current device is unlinked per a request via DeviceManager. The result is of the Device type and represents the unlinked device.
SessionManager accepts event callbacks extending SessionManager.BaseManagerEventCallback
GetSessionsEventCallback Event callback when a list of all active sessions have been fetched from LaunchKey. The result is of the List<Session> type.
EndSessionEventCallback Event callback when a particular session has been ended per a request via SessionManager. The result is of the Session type and represents the ended session.
EndAllSessionsEventCallback Event callback when all sessions havae been ended per a request via SessionManager. There is no result object.

Example: AuthenticatorManager Events

The following example uses AuthenticatorManager events to register for event notifications.:

//Define member variables for each callback

DeviceLinkedEventCallback mDeviceLinkedEvent = new DeviceLinkedEventCallback() {
            @Override
            public void onEventResult(boolean successful, BaseError error, Device device) {
                if (successful) {
                    final String deviceName = device.getName();
                    //Notify the End-user that the current device with name 'deviceName' is now linked.
               } else {
                    //Show the appropriate error message based on the 'error' object returned.
                }
            }
        };

DeviceUnlinkedEventCallback mDeviceUnlinkedEvent = new DeviceUnlinkedEventCallback() {
            @Override
            public void onEventResult(boolean successful, BaseError error, Object o) {
                //Notify the End-user the current device has been unlinked and
                // provide option to re-link if they so want.
            }
        };

//Register for both events via AuthenticatorManager (Usually in the onResume() callback of the Activity/Fragment)
AuthenticatorManager manager = AuthenticatorManager.getInstance();
manager.registerForEvents(mDeviceLinkedEvent, mDeviceUnlinkedEvent);

//Then unregister when done with the events (Usually in the onPause() callback of the Activity/Fragment)
manager.unregisterForEvents(mDeviceLinkedEvent, mDeviceUnlinkedEvent);

Example: AuthRequestManager

This manager handles all aspects to do with auth requests. The operational flow is as follows:

  1. Allow a view to get the singleton instance of AuthRequestManager.
  2. Register and unregister for specific events.
  3. React based on the callbacks and update the user interface.
  4. Trigger a request based on end-user actions.

For example:

//Get instance of the manager
AuthRequestManager manager = AuthRequestManager.getInstance();

//Define event callbacks
GetAuthRequestEventCallback getEvent = new GetAuthRequestEventCallback() {

    @Override
    public void onEventResult(boolean successful, BaseError error, AuthRequest authRequest) {

        if (successful) {
            //Create a notification if not in the View of the embedded AuthRequestFragment
            final ServiceProfile serviceProfile = authRequest.getServiceProfile();
            final String message = "Important message by ".concat(serviceProfile.getName());
            createNotificationForEndUser(message);
        } else {
            //Show message based on 'error' object returned
        }
    }
};

AuthRequestResponseEventCallback responseEvent = new AuthRequestResponseEventCallback() {

    @Override
    public void onEventResult(boolean successful, BaseError error, Boolean authorized) {

        if (successful) {
            //Update UI based on 'authorized'
        } else {
            //Show message based on 'error' object returned
       }
    }
};

//Register for events
manager.registerForEvents(getEvent, responseEvent);

//Check for any pending Auth Requests if not obtained already via Push Notifications
//Note: Push notifications require extra setup
manager.check()

//Unregister for events
manager.unregisterForEvents(getEvent, responseEvent);

//If you are providing a custom toolbar or user interface to deny Auth Requests
manager.denyAuthRequest();

Example: DeviceManager

The operational flow is as follows:

  1. Allow a view to get the singleton instance of DeviceManager.
  2. Register and unregister for specific events.
  3. React based on the callbacks and update the user interface.
  4. Trigger a request based on end-user actions.

For example:

//Get an instance of the manager
DeviceManager manager = DeviceManager.getInstance(context);

//Define event callbacks
GetDevicesEventCallback getDevicesEvent = new GetDevicesEventCallback() {

    @Override
    public void onEventResult(boolean successful, BaseError error, List<Device> devices) {

        if (successful) {
            //Update adapter with a new list of Device objects and update the user interface
        } else {
            //Show message based on the 'error' object returned
        }
    }
};

UnlinkDeviceEventCallback unlinkDeviceEvent = new UnlinkDeviceEventCallback() {

    @Override
    public void onEventResult(boolean successful, BaseError error, Device device) {

        if (successful) {
            //Notify how a device has been successfully unlinked--usually a request by the End-user
        } else {
            //Show message based on 'error' object returned
        }
    }
};

//Register for events
manager.registerForEvents(getDevicesEvent, unlinkDeviceEvent);
//Note: If there is already a list of devices, when a new event callback is
// registered, it is immediately notified of the list.

//Request update on list of devices
manager.getDevices();

//Unregister for events
manager.unregisterForEvents(getDevicesEvent, unlinkDeviceEvent);


//Request the unlinking of another device, action usually triggered by the End User


SimpleOperationCallback optionalOneTimeCallback = new SimpleOperationCallback {


   @Override
   public void onResult(boolean successful, BaseError error, Device device) {
       if (successful) {
           //Notify the end-user of the successful unlinking request on the 'device'
        } else {
            //Show a message based on the 'error' object returned
        }
    }
};

Device deviceToBeUnlinked = ...;
manager.unlinkDevice(deviceToBeUnlinked, optionalOneTimeCallback);
//Note: the optional callback can be a 'null' argument

Example: SessionManager

The operational flow to handle active sessions generated by one or more services is as follows:

  1. Allow a view to get the singleton instance of SessionManager.
  2. Register and unregister for specific events.
  3. React based on the callbacks and update the user interface.
  4. Trigger a request based on end-user actions.

For example:

//Get an instance of the manager
SessionManager manager = SessionManager.getInstance(context);

//Define event callbacks
GetSessionsEventCallback getSessionsEvent = new GetSessionsEventCallback() {

    @Override
    public void onEventResult(boolean successful, BaseError error, List<Sessions> sessions) {

        if (successful) {
            //Update the adapter with new list of Session objects and update UI
        } else {
            //Show a message based on 'error' object returned
        }
    }
};

EndSessionEventCallback endSessionEvent = new EndSessionEventCallback() {

    @Override
    public void onEventResult(boolean successful, BaseError error, Session session) {

        if (successful) {
            //Notify the end-user that the 'session' has been ended
        } else {
            //Show a message based on the returned 'error' object
        }
    }
};

EndAllSessionsEventCallback endAllSessionsEvent = new EndAllSessionsEventCallback() {

    @Override
    public void onEventResult(boolean successful, BaseError error, Object o) {

        if (successful) {
            //Notify the End User all active sessions have been ended
        } else {
            //Show message based on 'error' object returned
        }
    }
};

//Register for events
manager.registerForEvents(getSessionEvent, endSessionEvent, endAllSessionsEvent);

//Request an update on list of sessions
manager.getSessions();

//Unregister for events
manager.unregisterForEvents(getSessionEvent, endSessionEvent, endAllSessionsEvent);

//End a session
SimpleOperationCallback optionalOneTimeCallback = new SimpleOperationCallback {


    @Override
    public void onResult(boolean successful, BaseError error, Session session) {
        if (successful) {
            //Notify End User that 'session' has been ended
        } else {
            //Show message based on 'error' object returned
        }
    }
};

Session sessionToEnd = ...;
manager.endSession(sessionToEnd, optionalOneTimeCallback);
//Note: the optional callback can be a 'null' argument

Customizing the User Interface

Overview

You can optionally customize many user interface (UI) elements. To customize the UI, you must define an XML theme that overrides the default theme, and pass the overrides to the SDK via the AuthenticatorConfig method when the SDK is initialized.

Properties Reference

You can customize the following properties.

Property Type Description
authenticatorColorPrimary color Background in all toolbars
authenticatorColorPrimaryDark color Background of the top status bar (when supported by the OS)
authenticatorColorAccent color Accent color in interactive widgets
authenticatorColorBackground color Background of all other views (Activities and Fragments)
authenticatorColorBackgroundOverlay color Text laid over backgrounds (Recommend high contrast with authenticatorColorBackground
authenticatorColorButtonBackground color Background on all buttons
authenticatorColorButtonText color Text on buttons (Recommend high contrast with authenticatorColorButtonBackground
authenticatorToolbarBackground color Background for all toolbars; this overrides the primary color from AppCompat components
authenticatorToolbarItems color All text and icons inside the toolbar (Recommend high contrast with authenticatorToolbarBackground
authenticatorAuthSwitchTrackLight color Upper, light track in the auth slider
authenticatorAuthSwitchTrackDark color Bottom, dark track in the auth slider
authenticatorAuthSwitchThumbNormal color Slider thumb when idle / normal
authenticatorAuthSwitchThumbPressed color Slider thumb when active / pressed
authenticatorAuthToolbarVisibility visibility flag [visible, invisible, gone] Visibility flag for the included toolbar in AuthRequestFragment; by default this is gone
authenticatorHeadersVisibility visibility flag [visible, invisible, gone] Visibility flag for the headers when listing items in security views, general labels under toolbars; by default this is gone
authenticatorSecurityListIconsVisibility visibility flag [visible, invisible, gone] Visibility flag for the icons displayed beside each set security factor in the Security view; by default this is visible
authenticatorShowHelpIcons boolean [true, false] Visibility flag for the help icons that appear in the Security views; true by default
authenticatorPinPadButtonBackgroundDrawableSelector color selector Drawable selector for the button background of each button in the pin pad widget
authenticatorPinPadButtonOverlayColorSelector color selector Color selector for the text on each button on the PIN pad widget
authenticatorCirclePadMarksColor color Color for each hash mark on the Circle Code widget
authenticatorCirclePadHighlightColor color Solid color for the highlight and center pieces of the Circle Code widget
authenticatorFactorPinIcon drawable Icon used when listing the PIN Code widget as a security factor
authenticatorFactorCircleIcon drawable Icon used when listing the Circle Code widget as an security factor
authenticatorFactorBluetoothIcon drawable Icon used when listing Device Proximity as an security factor
authenticatorFactorGeofencingIcon drawable Icon used when listing Geofencing as a security factor
authenticatorFactorFingerprintIcon drawable Icon used when listing Fingerprint Scan as a security factor
authenticatorAuthRequestOngoingImageBluetooth drawable Icon used when passively authenticating Device Proximity
authenticatorAuthRequestOngoingImageGeofencing drawable Icon used when passively authenticating Geofencing
authenticatorAuthRequestOngoingImageFingerprint drawable Icon used when passively authenticating Fingerprint Scan

Example: UI Customization

First override the default XML theme. Custom properties might look like the following:

<style name="CustomOverridingTheme" parent="AuthenticatorTheme">
    <item name="authenticatorColorPrimary">#00BCD4</item>
    <item name="authenticatorColorPrimaryDark">#00838F</item>
    <item name="authenticatorColorAccent">#8c9eff</item>
    <item name="authenticatorColorBackground">#a0c1bf</item>
    <item name="authenticatorColorBackgroundOverlay">#2d3d3c</item>
</style>

Then pass the customizations to the AuthenticatorConfig method:

AuthenticatorConfig config = new AuthenticatorConfig.Builder(...)
    ...
    .theme(R.style.CustomTheme)
    .build();

    AuthenticatorManager manager = AuthenticatorConfig.getInstance();
    manager.initialize(config);

Adding Push Notifications to Your Integration

Overview

iovation recommends adding push notifications to your integrations in order to provide a better experience for end users. We also recommend providing a mechanism to manually review notifications, because push notifications depend on many interrelated systems to work, such as mobile carrier availability and Google performance.

The LaunchKey SDK provides all of the classes you need to implement push notifications. The configuration steps are:

  1. Update your AndroidManifest.xml file.
  2. Set up a Google Developers Console project at https://console.developers.google.com/.
  3. Configure the mobile app.
  4. In the LaunchKey Dashboard, update the directory's server key.

Updating the AndroidManifest.xml

To update your AndroidManifest.xml to support push notifications:

  1. Place the following permissions at the same level as the normal permissions:

    <!—- GCM-required package-based permissions —->
    <permission android:name="<YOUR PACKAGE>.permission.C2D_MESSAGE" android:protectionLevel="signature" />
    <uses-permission android:name="**<YOUR PACKAGE>**.permission.C2D_MESSAGE" />
    <!—- All other GCM-required permissions are part of the SDK manifest and will be merged by Android —->
    
  2. Add the following to the <application> tag. Note that <YOUR PACKAGE> refers to your app's package.:

    <!-- GCM's own service that will handle upcoming push notifications -->
    <receiver
       android:name="com.google.android.gms.gcm.GcmReceiver"
        android:permission="com.google.android.c2dm.permission.SEND" >
        <intent-filter>
            <action android:name="com.google.android.c2dm.intent.REGISTRATION" />
            <action android:name="com.google.android.c2dm.intent.RECEIVE" />
            <category android:name="**<YOUR PACKAGE>**" />
        </intent-filter>
    </receiver>
    
    <!-- The Authenticator SDK's service to process push notification -->
    <service
        android:name="...android.authenticator.sdk.gcm.GcmNotificationService"
        android:exported="false" >
        <intent-filter>
            <action android:name="com.google.android.c2dm.intent.RECEIVE" />
        </intent-filter>
    </service>
    
    <!-- The Authenticator SDK's service to handle the update of the device-level GCM token -->
    <service
        android:name="...android.authenticator.sdk.gcm.GcmInstanceIdListenerService"
        android:exported="false">
        <intent-filter>
            <action android:name="com.google.android.gms.iid.InstanceID"/>
        </intent-filter>
    </service>
    
    <!-- The Authenticator SDK's service to update the servers with the new GCM token -->
    <service
        android:name="...android.authenticator.sdk.gcm.GcmNotificationRegistrar"
        android:exported="false">
    </service>
    
    <!-- Google Play Services' required version declaration -->
    <meta-data
        android:name="com.google.android.gms.version"
        android:value="@integer/google_play_services_version" />
    

Setting Up Google Developers Console

Generate a server API key and a google-service.json file for your app:

  1. Go to the Google Developers Console at https://console.developers.google.com/.

  2. Open your Google Maps support project. This may be the same project that you use for push notifications.

  3. Open Library under API Manager and make sure that Google Maps for Android v2 is enabled.

  4. Under Credentials, create a new Android key and follow the instructions.

  5. Add the new key to the AndroidManifest.xml file. Place it under a <meta-data element with the android:name property set to com.google.android.geo.API_KEY. Write the key to an android:value property, for example:

    <!--Value API_KEY_HERE will be replaced with the actual key just generated -->
    <meta-data
        android:name="com.google.android.geo.API_KEY"
        android:value="API_KEY_HERE"
    />
    

User Contributed

LaunchKey links to user contributed code as a resource to its community. LaunchKey does not in any way guarantee or warrant the quality and security of these code bases. User contributed code is supported by the creators. If you do find a link from the site to user contributed code that is malicious or inappropriate in any way, please report that link to LaunchKey immediately and we will investigate the claim. Submit any issue to LaunchKey support at https://launchkey.com./support. ×