Android studio application id suffix

Package Name vs. Application ID

All Android developers should understand that the Package Name that we choose for our app is very important. I’m referring to the Package Name of the application itself (which gets declared in the Manifest) rather than the Java package name (although often they will be identical. It was only recently, when I was tackling a somewhat obscure issue as part of my day job, that I realised that there is actually a subtle, but important, difference between the Package Name and the Application ID. In this article we’ll look at the difference between the two.

Let’s begin with a reminder of the basics. The Package Name is, as we’ve already mentioned, defined as part of the Manifest and represents the identity of any given app both on an individual device, and on the Google Play store (or any other app store for that matter). Therefore your package name has to be unique. However it is sometimes useful to be able to produce separate APKs with different identities (e.g. different IDs for debug & release builds so that they can be published as distinct entities in Fabric Beta). To facilitate this we can control the applicationId in our build.gradle and this enables us have distinct package names. We can see this in a simple project. The common Manifest is defined like this:

We have a base package name of com.stylingandroid.packagename . Next we have our build.gradle :

Here we add a distinct suffix to the applicationId for both debug and release builds. It is possible to override the entire applicationId (i.e. replace the whole of the package name with the applicationId , but we’ll just add a suffix here.

If we now compare the two Manifests which get added to the two APKs we can see how distinct package names are specified in each Manifest:

There should be nothing here that should be surprising to the vast majority of Android developers, but from here on it is important to understand the difference between the Package Name – which gets declared up-front in the base Manifest; and the application ID – which gets declared in our build.gradle . The package name controls much of what occurs during the build, but the application ID only gets applied right at the very end. For proof of this, take a look here, specifically the final note which states:

Although you may have a different name for the manifest package and the Gradle applicationId, the build tools copy the application ID into your APK’s final manifest file at the end of the build

(The emphasis of the word end is mine)

So why is this important? Let’s begin by adding some code to our main Activity firstly a simple layout containing two TextViews:

To the Activity itself we’ll add some code to set these to the package name & the applicationId:

The three highlighted lines actually explain what happens during the build.

The first thing to note is the Java package name of MainActivity itself. As is normal we have matched this to the package name which we initially defined in the Manifest (shown earlier).

Secondly, when we come to reference our BuildConfig, we don’t need to fully qualify the package name, or import the package. That is because the BuildConfig.java and R.java both got generated in the package name that was specified originally in the Manifest – com.stylingandroid.packagename .

Thirdly, although the package name has not been set in the Manifest at the point when our code is compiled, we can still gain access to the final application ID for the current build flavor via the BuildConfig.APPLICATION_ID constant.

If we run this code it confirms this:

This won’t cause anyone any issues in the vast majority of cases but if, for example, you are generating code from an annotation processor, it can be important to understand when to use the package name over the applicationId and vice versa.

So, why is it left so late to set the applicationID? The simple reason is that it would cause no end of problems if it was set earlier in the process. If the BuildConfig.java and R.java files was set to the applicationId rather than the package name, then the code which referenced these would need to have different imports for different build variants – in other words you would need to have separate source sets (with huge amounts of duplication) for your different build flavors in order to access these. This would have some quite profound implications for the maintainability of our code.

As I have said, an understanding of precisely how this all works is not necessary for developers to be able to write android apps. But if, like me, you encounter some issues with generating code in the correct java package then this can be invaluable. When I was searching for information on this, the only thing I could find was the page on the official documentation (which I quoted and linked to earlier), so it seemed worth sharing what I learned. Apologies to anyone expecting the usual UI/UX-centric subject matter but hopefully this will be of interest to many as us developers are an inquisitive bunch!

The source code for this article is available here.

Источник

Android Package Name Vs Application ID

Creating multiple APKs for different purposes.

PackageName vs ApplicationId

Nowadays, many times we come to the situation that we need the APK with another different package name. Most of us do it easily, but sometimes we got stuck because of applicationId and packageName.We must know the difference between packageName and applicationId. And the other thing is Java package.

The following are the three which keeps us confusing:

1. applicationId: BuildConfig.APPLICATION_ID
2. packageName: getApplicationContext().getPackageName()
3. Java package: BuildConfig.class.getPackage().toString()

Let’s see with an example

The following is the snippet from the gradle of a sample Android application.

Here we will be having two different APKs.

1. Release APK with com.mindorks.example.release
2. Debug APK with com.mindorks.example.debug

The following is the snippet from manifest of the same sample Android application.

The following is the project package snippet of the same sample Android application.

So, let’s create a debug APK and see what are the values of all the three.

Read the values carefully.

The following shows the final AndroidManifest file after APK creation.

getPackageName gives the same applicationId which is created at the final moment from the gradle file and it overrides the AndroidManifest package. So the final AndroidManifest contains the same applicationId. So, the getPackageName is the same as the applicationId as the applicationId overrides the packageName in the AndroidManifest at the final moment.

But for the Java code, the package is same as the project structure. The package that is used in your source code to refer to your R class, and to resolve any relative activity, service registrations, continues to be called the package as defined in your manifest. So, the AndroidManifest should have the package same as Java package to resolve relative activity, service.

So, with the same java package, we can create any number of APKs with all unique applicationId.

But the final AndroidManifest contains the package as the unique applicationId only.

If you have to actually change the structure of your project, then you have to change your packageName in Manifest.xml.

If you rename the package name from manifest file, it will have NO impact on the applicationId even if they have the same name.

We can also create multiple APKs through productFlavors like above.

Remember, once an app has been published to Google Play store, the ApplicationId should never be changed.

Источник

How to change Android application ID

The application ID (application package) defines the unique identity for an app. It must be universally unique in order to publish an app on Google Play Store. Every Android app has a unique application ID that looks like a Java package name, such as com.example.myapp. A user cannot deploy apps with the same application ID on the same device simultaneously. And, if you change it, the APK is considered to be a different app and users of the previous version will not receive an update. The application ID is specified in the package attribute of the manifest element as application package.

When you create a new project in Android Studio, the applicationId exactly matches the Java-style package name you chose during setup. However, the application ID and package name are independent of each other beyond this point. You can change your code’s package name (your code namespace) and it will not affect the application ID, and vice versa. You can either change the application ID through rename refactoring, or on build time. And although the application ID looks like a traditional Java package name, the naming rules for the application ID are a bit more restrictive:

• It must have at least two segments (one or more dots)
• Each segment must start with a letter
• All characters must be alphanumeric or an underscore [a-z, 0-9, _]

1. Through rename refactoring

Follow these steps to rename Android application ID through rename factoring.

Источник

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.

Источник