What is meant by bundle ID in android, What is its usage, And can two android apps have same bundle ID? if YES then why? and if NO then why
A bundle ID otherwise known as a package in Android is the unique identifier for all Android apps. It needs to be unique as when you upload it to Google Play it identifies and publishes your app using the package name as the unique app identification.
Really it is the only thing which is necessary to identify your app, and generally it has 3 parts:
com.example.testapp
Where example is generally the company/publishers name, and testapp is the appname.
You will not be able to upload an APK to the store which has the same package as another app already in the store.
Should you ever need to change the package name in Eclipse, do the following:
Right click project > Android Tools > Rename Application Package...
BundleID is a Unique Identifier for Identifying your app on Google Play Store. You can Note that for each apps on Google Play something like this:
https://play.google.com/store/apps/details?id = com.yourdomain.appname
You cannot assign the same BundleId for more than one App. This is because the Google Play uses your BundleID as Unique Identifier for your app.
So, you can configure your BundleID in Android Studio by editing your applicationId property in app level gradle as shown below:
android {
compileSdkVersion 27
defaultConfig {
//Edit the applicationId for changing your BundeID.
applicationId "com.yourdomainname.yourappname"
minSdkVersion 15
targetSdkVersion 27
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
Related
I am trying to upload an application under development to Google Play Console, internal testing track. The application has two flavor dimensions and and two dynamic features, the last two being resources only (no code). I am relying on Android Studio to generate the directory structure and the signed bundle.
The name of the package is com.something.something. The upload fails with the message "Your APK or Android App Bundle needs to have the package name com.something.something.base."
I cannot track down the source of the problem, though it looks like it should have something to do with the flavor dimensions. On the other hand, I had no problem uploading a single apk, without the dynamic features.
I am not sure which part of the code is relevant here, which is probably part of my problem, but my main build gradle looks like this
apply plugin: 'com.android.application'
android {
compileSdkVersion 27
defaultConfig {
applicationId 'com.something.something'
....
}
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
//testCoverageEnabled false
}
}
flavorDimensions "version"
productFlavors {
small {
dimension "version"
}
full {
dimension "version"
}
}
dynamicFeatures = [":feat1", ":feat2"]
}
dependencies {
...
}
I do not want to burden the question with irrelevant code, but can provide more if there is some intuition about where the problem might be.
I would be grateful for any suggestion on how to approach the debugging here. (Uploading is painfully slow, trial and error is not much of an option.)
Thank you all for taking a shot at the answer. Here is what I learned about this issue and how I "solved" it.
My problem starts with Google Play Console (GPC) insisting that an app name be associated with the very first package name you have uploaded. This is in addition to having one app = one package name rule. If you are still in the draft stage, you can delete the package from your "All applications" list in GPC, and upload a package with different name, but once it's published - no such luck. The way GPC is designed, all my future uploads should have the suffix ".base", if this is what my first upload had.
Next, Android Studio (AS), does something called manifest file merging. (#Fantômas, your audience may not be as omniscient as you are - the behavior of AS is relevant here, and with your permission I would return the tag.) When you choose the flavor for the bundle, the name of the flavor is suffixed to create the package name in the merged AndroidManifest file, irrespective of the name you specify in your main AndroidManifest.xml, as you can check if you choose to "analyze" (the name of the link after the bundle is generated) newly created bundle:
Thus, in my first upload I had a flavor called base, and I did not realize that AS tacked it as the suffix on the name of my package. From that point on, GPC will not take a package for my app by any other name.
One thing that is irrelevant here are dynamic features - they just happened to be part of my second upload attempt.
I have asked Google to delete my app so I can start from scratch.
Since your problem is not related to codes, try changing your package name to something else, something more "unique".
com.myname.myappname is an example. In this case you need to change everything related to your package name. Try it and report back
You do not need to delete your app from Google console. Simply open Build.gradle(Module:app) in your android studio and change the Application Id to the name google is requesting from you.
You will need to change your Application Id in your Build.Gradle(Module: app)
You may also need to change the name in your google-services.json file under this section:
"client_info": {
"mobilesdk_app_id": "...",
"android_client_info": {
"package_name": "com.yourpackagename.yourpackagename"
}
good coding!!
You can avoid "Manifest file merging" (of Android Studio...) to altering the package name of the "merged manifest" in the build variant, by excluding the applicationIdSuffix definition on the build type or flavour dimmension definition in the build.gradle (app: module), like in my following example, in what I want to avoid to adding the respective package name suffixes ".release" and ".full" in my "release" and/or "full" versions of my App:
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
// applicationIdSuffix ".release"
versionNameSuffix "-release"
}
debug {
proguardFiles 'proguard-project.txt'
applicationIdSuffix ".debug"
versionNameSuffix "-debug"
}
}
// Specifies one flavor dimension.
flavorDimensions "version"
productFlavors {
free {
dimension "version"
applicationIdSuffix ".free"
versionNameSuffix "-free"
}
full {
dimension "version"
// applicationIdSuffix ".full"
versionNameSuffix "-full"
}
}
Regards,
P.D.:
And thanks a lot for all the other answers, that help me in this moment to take this my decission of doing the above posted... Thanks, especially for #celaeno, that explained how works the "Manifest merging" in Android Studio, and over all, advertised how App Id SUFFIXES may CHANGE the App.Id in Google Play Console terms...
change the applicationId in android/app/build.gradle to the same id of the previos versions.
defaultConfig {
applicationId "com.xxxxxxx.xxxx"
minSdkVersion rootProject.ext.minSdkVersion
targetSdkVersion rootProject.ext.targetSdkVersion
versionCode 12
versionName "3.2.0"
multiDexEnabled true
vectorDrawables.useSupportLibrary = true
targetSdkVersion 30
missingDimensionStrategy 'react-native-camera', 'general'
}
we know APK save data in /data/data/PackageName，if two different apk with same package name,will they cover other's data?(like sharepreference's data)
The Answer is No, Why? This is not possible, Play store will not let you to upload an apk with the same package,Package name at play store is important for many reasons, one of them is update detection, if you updated an application the first thing Google pay attention is the package name in order to know what is the current release version.
Somehow it will be happened by same developer at the DEVELOPMENT stage only then you can name your package whatever do you want.
As far as same package name is concerned it's not possible to have installed on same device it will be replaced.
But if we have different appliationId, yes another app can be installed on same device but in that case packageName will also be change.
Working Sample
Project 1
app/build.gradle
applicationId "com.test.sample"
Android Manifest
package="com.test.sample"
Result
When i print applicationId and package name, it was same:
applicationId: "com.test.sample"
package: "com.test.sample"
Project 2
I've added buildTypes/flavor but keeping applicationId and package name same, but in that case outpout of applicationId and package name will be changed.
build.gradle(app)
applicationId "com.test.sample"
buildTypes {
release {
applicationIdSuffix ".release"
}
debug {
applicationIdSuffix ".debug"
}
}
Android Manifest
package="com.test.sample"
Result
When i print applicationId and package name, it was different:
applicationId: "com.test.sample.debug"
package: "com.test.sample.debug"
So that is how two applications are installed due to change in buildType/flavors(pro/free).
And if you want to access sharedPreferences of each-other (assume free/pro version) than you need to create a ContentProvider to expose data you need and grant permissions to paid app.
i started working on a project on android studio , initially i didn't know if I would go to launch the app so i let the package name be the same as given by android studio by default ( it was com.example.abhishek.tv ) .
Now I'm done with the app and want to launch it but here I got stuck as I'm having my domain name as abhishekint.16m.com but i don't know to change the default package name given by android studio .
I have three problems here
I don't know to change the package name efficiently and SAFELY. I'm reluctant while changing the package name after reading some of the stackoverflow links as I was not clear with the answer and package name seems very sensible as it can ruin the whole project if not done properly .
My original domain name has numerics and I found after searching online that there is something abnormal with the numeric domain name .
One more thing , as I've this app which has some of the videos from youtube so in case if I choose to change the package name of my project then will I have to change the package name of the API_KEY that i got after fingerprinting while getting the youtube API .
Change in your app-level build.gradle file
android {
compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
applicationId "com.abc.xyz" // change here
minSdkVersion 16
targetSdkVersion 25
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
This will override package name that exist in AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.abc.xyz">
<uses-permission android:name="android.permission.INTERNET"></uses-permission>
<application
EDIT
From the documentation about naming packages in Java:
In some cases, the internet domain name may not be a valid package
name. This can occur if the domain name contains a hyphen or other
special character, if the package name begins with a digit or other
character that is illegal to use as the beginning of a Java name
This means you can't use a digit as the first character of a package (or a class, interface or variable name, for that matter).
abhishekint.16m.com not allowed but you can use abhishekint.sixteenm.com.
I have app on git with package for example com.foo.
Now I want to create clone of this app with different name.
In order to do it I fork my app and change the name. But this app has the same package.
And I can't install the second app because they have same package name.
What would be the best way to support two apps with same functions but different names?
Create different productFlavors for another app in same code
productFlavors {
VersionFirst {
applicationId "packagename"
versionName "1.0"
}
VersionSecond {
applicationId "packagename"
versionName "1.0"
}
}
generate different build using build varient
If two applications have the same package name, only one of them will be installed. If they share the same signature, installing the second package will overwrite the first assuming it doesn't downgrade the version. If they have different signatures, you'll get an error saying that you can't install the second package.
Read this :https://developer.android.com/guide/topics/manifest/manifest-element.html
In an Android project, the resource ids are fully identified by the application id. For example, if my appid is com.mycompany.myapp, the resource id would be com.mycompany.myapp.R.blah.
In my case, I need to create two versions of the app - beta version and release version. Both the versions may be installed on the same device. This can happen only if the appids are not the same. My strategy is, during the nightly build, I will programmatically modify the manifest file and change the appid to com.mycompany.myappbeta. However, if I do this, I would need to touch a number of source files that are using the resource ids.
I am wondering if there is some token in the manifest file where I can explicitly say how the resource ids be qualified? Regards.
Edit
It turns out app id and package id are indeed two different concepts. I wanted to change the app-id but not the package-id. However, it seems this is not possible under Eclipse. As other posts have pointed out, Gradle build can handle changing the app-id but retaining the package id. I am moving over to Android Studio now.
the resource ids are fully identified by the application id
Technically, they are identified by the package name, from the package attribute in the root manifest.
My strategy is, during the nightly build, I will programmatically modify the manifest file and change the appid to com.mycompany.myappbeta. However, if I do this, I would need to touch a number of source files that are using the resource ids.
Which is why your nightly build should be using Gradle and the Gradle for Android plugin. Then, you skip all of what you described, and instead use build types. Two build types (debug and release) are pre-defined, and if you want to invent another one (e.g., beta), you can. Then, in the build type configuration in your build.gradle file, you use applicationIdSuffix to give non-release builds a distinct suffix. That will be added to the application ID for the purposes of unique installations, but your package name is unaffected, so your resources are unaffected.
For example:
android {
compileSdkVersion 19
buildToolsVersion "21.1.2"
defaultConfig {
versionCode 2
versionName "1.1"
minSdkVersion 14
targetSdkVersion 18
}
signingConfigs {
release {
storeFile file('HelloConfig.keystore')
keyAlias 'HelloConfig'
storePassword 'laser.yams.heady.testy'
keyPassword 'fw.stabs.steady.wool'
}
}
buildTypes {
debug {
applicationIdSuffix ".d"
}
release {
signingConfig signingConfigs.release
}
beta.initWith(buildTypes.release)
beta {
applicationIdSuffix ".beta"
debuggable true
}
}
}
Here I:
Give the debug build type an application ID suffix of .d
Leave the release build type along from the standpoint of an application ID suffix
Create a new beta build type, cloned from the release build type, where I give it a .beta application ID suffix and mark it as debuggable
However, if I do this, I would need to touch a number of source files that are using the resource ids.
No, you will not. You just need to change package id in your Manifest file only, ensuring however all services and activities listed in manifest file are using full class path, i.e.:
android:name="com.mycompany.myapp.MainActivity"
not just shortened notation:
android:name=".MainActivity"
as this make your app not working when package Id will not match with your code packages.