Android sign app with debug key

Signing Your Applications

In this document

See also

Android requires that all apps be digitally signed with a certificate before they can be installed. Android uses this certificate to identify the author of an app, and the certificate does not need to be signed by a certificate authority. Android apps often use self-signed certificates. The app developer holds the certificate’s private key.

Signing Overview

You can sign an app in debug or release mode. You sign your app in debug mode during development and in release mode when you are ready to distribute your app. The Android SDK generates a certificate to sign apps in debug mode. To sign apps in release mode, you need to generate your own certificate.

Signing in Debug Mode

In debug mode, you sign your app with a debug certificate generated by the Android SDK tools. This certificate has a private key with a known password, so you can run and debug your app without typing the password every time you make a change to your project.

Android Studio signs your app in debug mode automatically when you run or debug your project from the IDE.

You can run and debug an app signed in debug mode on the emulator and on devices connected to your development manchine through USB, but you cannot distribute an app signed in debug mode.

By default, the debug configuration uses a debug keystore, with a known password and a default key with a known password. The debug keystore is located in $HOME/.android/debug.keystore, and is created if not present. The debug build type is set to use this debug SigningConfig automatically.

For more information about how to build and run apps in debug mode, see Building and Running.

Signing in Release Mode

In release mode, you sign your app with your own certificate:

1. Create a keystore. A keystore is a binary file that contains a set of private keys. You must keep your keystore in a safe and secure place.
2. Create a private key. A private key represents the entity to be identified with the app, such as a person or a company.

Add the signing configuration to the build file for the app module:

Invoke the assembleRelease build task from Android Studio.

The package in app/build/apk/app-release.apk is now signed with your release key.

Note: Including the passwords for your release key and keystore inside the build file is not a good security practice. Alternatively, you can configure the build file to obtain these passwords from environment variables or have the build process prompt you for these passwords.

To obtain these passwords from environment variables:

To have the build process prompt you for these passwords if you are invoking the build from the command line:

After you complete this process, you can distribute your app and publish it on Google Play.

Warning: Keep your keystore and private key in a safe and secure place, and ensure that you have secure backups of them. If you publish an app to Google Play and then lose the key with which you signed your app, you will not be able to publish any updates to your app, since you must always sign all versions of your app with the same key.

The rest of this document provides detailed instructions about how to generate a private key and sign your apps in release mode with Android Studio.

Signing Android Wear Apps

When publishing Android Wear apps, you package the wearable app inside of a handheld app, because users cannot browse and install apps directly on the wearable. Both apps must be signed. For more information on packaging and signing Android Wear apps, see Packaging Wearable Apps.

Signing Your App in Android Studio

To sign your app in release mode in Android Studio, follow these steps:

On the menu bar, click Build >Generate Signed APK.

On the Generate Signed APK Wizard window, click Create new to create a new keystore.

If you already have a keystore, go to step 4.

On the New Key Store window, provide the required information as shown in figure 1.

Your key should be valid for at least 25 years, so you can sign app updates with the same key through the lifespan of your app.

Figure 1. Create a new keystore in Android Studio.

On the Generate Signed APK Wizard window, select a keystore, a private key, and enter the passwords for both. Then click Next.

Figure 2. Select a private key in Android Studio.

On the next window, select a destination for the signed APK and click Finish.

Figure 3. Generate a signed APK in Android Studio.

Automatically Signing Your App

In Android Studio, you can configure your project to sign your release APK automatically during the build process:

1. On the project browser, right click on your app and select Open Module Settings.
2. On the Project Structure window, select your app’s module under Modules.
3. Click on the Signing tab.

Select your keystore file, enter a name for this signing configuration (as you may create more than one), and enter the required information.

Figure 4. Create a signing configuration in Android Studio.

Under Signing Config, select the signing configuration you just created.

Figure 5. Select a signing configuration in Android Studio.

You can also specify your signing settings in Gradle configuration files. For more information, see Configuring Gradle Builds.

Signing Considerations

You should sign all of your apps with the same certificate throughout the expected lifespan of your applications. There are several reasons why you should do so:

• App upgrade: When the system is installing an update to an app, it compares the certificate(s) in the new version with those in the existing version. The system allows the update if the certificates match. If you sign the new version with a different certificate, you must assign a different package name to the application—in this case, the user installs the new version as a completely new application.
• App modularity: Android allows apps signed by the same certificate to run in the same process, if the applications so requests, so that the system treats them as a single application. In this way you can deploy your app in modules, and users can update each of the modules independently.
• Code/data sharing through permissions: Android provides signature-based permissions enforcement, so that an app can expose functionality to another app that is signed with a specified certificate. By signing multiple apps with the same certificate and using signature-based permissions checks, your apps can share code and data in a secure manner.

If you plan to support upgrades for an app, ensure that your key has a validity period that exceeds the expected lifespan of that app. A validity period of 25 years or more is recommended. When your key’s validity period expires, users will no longer be able to seamlessly upgrade to new versions of your application.

If you plan to publish your apps on Google Play, the key you use to sign these apps must have a validity period ending after 22 October 2033. Google Play enforces this requirement to ensure that users can seamlessly upgrade apps when new versions are available.

Securing Your Private Key

Maintaining the security of your private key is of critical importance, both to you and to the user. If you allow someone to use your key, or if you leave your keystore and passwords in an unsecured location such that a third-party could find and use them, your authoring identity and the trust of the user are compromised.

If a third party should manage to take your key without your knowledge or permission, that person could sign and distribute apps that maliciously replace your authentic apps or corrupt them. Such a person could also sign and distribute apps under your identity that attack other apps or the system itself, or corrupt or steal user data.

Your private key is required for signing all future versions of your app. If you lose or misplace your key, you will not be able to publish updates to your existing appn. You cannot regenerate a previously generated key.

Your reputation as a developer entity depends on your securing your private key properly, at all times, until the key is expired. Here are some tips for keeping your key secure:

• Select strong passwords for the keystore and key.
• Do not give or lend anyone your private key, and do not let unauthorized persons know your keystore and key passwords.
• Keep the keystore file containing your private key in a safe, secure place.

In general, if you follow common-sense precautions when generating, using, and storing your key, it will remain secure.

Expiry of the Debug Certificate

The self-signed certificate used to sign your application in debug mode has an expiration date of 365 days from its creation date. When the certificate expires, you will get a build error.

To fix this problem, simply delete the debug.keystore file. The default storage location is in

/.android/ on OS X and Linux, in C:\Documents and Settings\ \.android\ on Windows XP, and in C:\Users\ \.android\ on Windows Vista and Windows 7.

The next time you build, the build tools will regenerate a new keystore and debug key.

Note that, if your development machine is using a non-Gregorian locale, the build tools may erroneously generate an already-expired debug certificate, so that you get an error when trying to compile your application. For workaround information, see the troubleshooting topic I can’t compile my app because the build tools generated an expired debug certificate.

Signing Your App Manually

You do not need Android Studio to sign your app. You can sign your app from the command line using standard tools from the Android SDK and the JDK. To sign an app in release mode from the command line:

Generate a private key using keytool . For example:

This example prompts you for passwords for the keystore and key, and to provide the Distinguished Name fields for your key. It then generates the keystore as a file called my-release-key.keystore . The keystore contains a single key, valid for 10000 days. The alias is a name that you will use later when signing your app.

Compile your app in release mode to obtain an unsigned APK.

Sign your app with your private key using jarsigner :

This example prompts you for passwords for the keystore and key. It then modifies the APK in-place to sign it. Note that you can sign an APK multiple times with different keys.

Verify that your APK is signed. For example:

Align the final APK package using zipalign .

zipalign ensures that all uncompressed data starts with a particular byte alignment relative to the start of the file, which reduces the amount of RAM consumed by an app.

Источник

Authenticating Your Client

Certain Google Play services (such as Google Sign-in and App Invites) require you to provide the SHA-1 of your signing certificate so we can create an OAuth2 client and API key for your app.

Using Play App Signing

If you’ve published your app using Play App Signing, a requirement when using Android App Bundle, you can get your SHA-1 from the Google Play Console on the Release > Setup > App Integrity page.

Self-signing Your Application

If you’re not using Play App Signing, follow the instructions below to use Keytool or Gradle’s Signing Report to get your SHA-1.

Using Keytool on the certificate

Open a terminal and run the keytool utility provided with Java to get the SHA-1 fingerprint of the certificate. You should get both the release and debug certificate fingerprints.

To get the release certificate fingerprint:

To get the debug certificate fingerprint:

The keytool utility prompts you to enter a password for the keystore. The default password for the debug keystore is android . The keytool then prints the fingerprint to the terminal. For example:

Using Keytool on an APK or AAB

To get the certificate of an application binary:

Using Gradle’s Signing Report

You can also get the SHA-1 of your signing certificate using the Gradle signingReport command:

The signing report will include the signing information for each of your app’s variants:

To learn more about digital signing on Android, see Signing Your Applications.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Источник

Debugging with Android Studio

In this document

See also

Android Studio enables you to debug apps running on the emulator or on an Android device. With Android Studio, you can:

• Select a device to debug your app on.
• View the system log.
• Set breakpoints in your code.
• Examine variables and evaluate expressions at run time.
• Run the debugging tools from the Android SDK.
• Capture screenshots and videos of your app.

To debug your app, Android Studio builds a debuggable version of your app, connects to a device or to the emulator, installs the app and runs it. The IDE shows the system log while your app is running and provides debugging tools to filter log messages, work with breakpoints, and control the execution flow.

Run your App in Debug Mode

Figure 1. The Choose Device window enables you to select a physical Android device or a virtual device to debug your app.

To run your app in debug mode, you build an APK signed with a debug key and install it on a physical Android device or on the Android emulator. To set up an Android device for development, see Using Hardware Devices. For more information about the emulator provided by the Android SDK, see Using the Emulator.

To debug your app in Android Studio:

1. Open your project in Android Studio.
2. Click Debug in the toolbar.
3. On the Choose Device window, select a hardware device from the list or choose a virtual device.
4. Click OK. Your app starts on the selected device.

Figure 1 shows the Choose Device window. The list shows all the Android devices connected to your computer. Select Launch Emulator to use an Android virtual device instead. Click the ellipsis to open the Android Virtual Device Manager.

Android Studio opens the Debug tool window when you debug your app. To open the Debug window manually, click Debug . This window shows threads and variables in the Debugger tab, the device status in the Console tab, and the system log in the Logcat tab. The Debug tool window also provides other debugging tools covered in the following sections.

Figure 2. The Debug tool window in Android Studio showing the current thread and the object tree for a variable.

Attach the debugger to a running process

You don’t always have to restart your app to debug it. To debug an app that you’re already running:

1. Click Attach debugger to Android proccess.
2. In the Choose Process window, select the device and app you want to attach the debugger to.
3. To open the Debug tool window, click Debug .

Use the System Log

The system log shows system messages while you debug your app. These messages include information from apps running on the device. If you want to use the system log to debug your app, make sure your code writes log messages and prints the stack trace for exceptions while your app is in the development phase.

Write log messages in your code

To write log messages in your code, use the Log class. Log messages help you understand the execution flow by collecting the system debug output while you interact with your app. Log messages can tell you what part of your application failed. For more information about logging, see Reading and Writing Logs.

The following example shows how you might add log messages to determine if previous state information is available when your activity starts:

During development, your code can also catch exceptions and write the stack trace to the system log:

Note: Remove debug log messages and stack trace print calls from your code when you are ready to publish your app. You could do this by setting a DEBUG flag and placing debug log messages inside conditional statements.

View the system log

Both the Android DDMS (Dalvik Debug Monitor Server) and the Debug tool windows show the system log; however, the Android DDMS tool window lets you view only log messages for a particular process. To view the system log on the Android DDMS tool window:

1. Start your app as described in Run your App in Debug Mode.
2. Click Androidto open the Android DDMS tool window.
3. If the system log is empty in the Logcat view, click Restart.

Figure 4. The system log in the Android DDMS tool window.

The Android DDMS tool window gives you access to some DDMS features from Android Studio. For more information about DDMS, see Using DDMS.

The system log shows messages from Android services and other Android apps. To filter the log messages to view only the ones you are interested in, use the tools in the Android DDMS window:

• To show only log messages for a particular process, select the process in the Devices view and then click Only Show Logcat from Selected Process. If the Devices view is not available, click Restore Devices Viewon the right of the Android DDMS tool window. This button is only visible when you hide the Devices window.
• To filter log messages by log level, select a level under Log Level on the top of the Android DDMS window.
• To show only log messages that contain a particular string, enter the string in the search box and press Enter.

Work with Breakpoints

Breakpoints enable you to pause the execution of your app at a particular line of code, examine variables, evaluate expressions, and continue the execution line by line. Use breakpoints to determine the causes of run-time errors that you can’t fix by looking at your code only. To debug your app using breakpoints:

1. Open the source file in which you want to set a breakpoint.
2. Locate the line where you want to set a breakpoint and click on it.
3. Click on the yellow portion of the side bar to the left of this line, as shown in figure 5.
4. Start your app as described in Run your App in Debug Mode.

Android Studio pauses the execution of your app when it reaches the breakpoint. You can then use the tools in the Debug tool window to identify the cause of the error.

Figure 5. A red dot appears next to the line when you set a breakpoint.

View and configure breakpoints

To view all the breakpoints and configure breakpoint settings, click View Breakpoints on the left side of the Debug tool window. The Breakpoints window appears, as shown in figure 6.

Figure 6. The Breakpoints window lists all the current breakpoints and includes behavior settings for each.

The Breakpoints window lets you enable or disable each breakpoint from the list on the left. If a breakpoint is disabled, Android Studio does not pause your app when it hits that breakpoint. Select a breakpoint from the list to configure its settings. You can configure a breakpoint to be disabled at first and have the system enable it after a different breakpoint is hit. You can also configure whether a breakpoint should be disabled after it is hit. To set a breakpoint for any exception, select Exception Breakpoints in the list of breakpoints.

Debug your app with breakpoints

After you set breakpoints in your code, click Rerun to start the app again. When a breakpoint is hit, Android Studio pauses the app and highlights the breakpoint in the source code. The Debug tool window lets you examine variables and control the execution step by step:

To examine the object tree for a variable, expand it in the Variables view. If the Variables view is not visible, click Restore Variables View .

To evaluate an expression at the current execution point, click Evaluate Expression .

To advance to the next line in the code (without entering a method), click Step Over .

To advance to the first line inside a method call, click Step Into .

To advance to the next line outside the current method, click Step Out .

To continue running the app normally, click Resume Program .

Figure 7. The Variables view in the Debug tool window.

Track Object Allocation

Android Studio lets you track objects that are being allocated on the Java heap and see which classes and threads are allocating these objects. This allows you to see the list of objects allocated during a period of interest. This information is valuable for assessing memory usage that can affect application performance.

To track memory allocation of objects:

1. Start your app as described in Run Your App in Debug Mode.
2. Click Androidto open the Android DDMS tool window.
3. On the Android DDMS tool window, select the Devices | logcat tab.
4. Select your device from the dropdown list.
5. Select your app by its package name from the list of running apps.
6. Click Start Allocation Tracking
7. Interact with your app on the device.
8. Click Stop Allocation Tracking

Android Studio shows the objects that the system allocated with the following information:

• Allocation order
• Allocated class
• Allocation size
• Thread ID
• Allocation method, class, and line number
• Stack trace at the point of allocation

Figure 8. Object allocation tracking in Android Studio.

Analyze Runtime Metrics to Optimize your App

Even if your application does not generate runtime errors, this does not mean it is free of problems. You should also consider the following issues:

• Does your app use memory efficiently?
• Does your app generate unnecessary network traffic?
• What methods should you focus your attention on to improve the performance of your app?
• Does your app behave properly when the user receives a phone call or a message?

The Android Device Monitor is a stand-alone tool with a graphical user interface for serveral Android application debugging and analysis tools, including the Dalvik Debug Monitor Server (DDMS). You can use the Android Device Monitor to analyze memory usage, profile methods, monitor network traffic and simulate incoming calls and messages.

To open the Android Device Monitor from Android Studio, click Monitor on the toolbar. The Android Device Monitor opens in a new window.

For more information about the Android Device Monitor and DDMS, see Device Monitor and Using DDMS.

Capture Screenshots and Videos

Android Studio enables you to capture a screenshot or a short video of the device screen while your app is running. Screenshots and videos are useful as promotional materials for your app, and you can also attach them to bug reports that you send to your development team.

To take a screenshot of your app:

1. Start your app as described in Run your App in Debug Mode.
2. Click Androidto open the Android DDMS tool window.
3. Click Screen Captureon the left side of the Android DDMS tool window.
4. Optional: To add a device frame around your screenshot, enable the Frame screenshot option.
5. Click Save.

To take a video recording of your app:

1. Start your app as described in Run your App in Debug Mode.
2. Click Androidto open the Android DDMS tool window.
3. Click Screen Recordon the left side of the Android DDMS tool window.
4. Click Start Recording.
5. Interact with your app.
6. Click Stop Recording.
7. Enter a file name for the recording and click OK.

Источник