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.
Related
I have an app uploaded to the play store. The package is: com.pathapp but then with gradle are generated two apk, com.path debug and release (without app). Now I want to integrate firebase, but I do not know what name of the app is what I have to put in firebase, if com.path or com.pathapp in order to have a well constructed google-services.json file.
If I change the original package of the directories from pathapp to path, there would be a problem?
android {
compileSdkVersion 27
defaultConfig {
applicationId "com.example"
minSdkVersion 16
targetSdkVersion 26
versionCode 1
versionName "1.00"
}
}
applicationId in the gradle is your package name.
So you need to add that in the firebase console.
In the above example, the package name is com.example. Likewise, check your gradle.
If you go to the Play Store you can see the package name of your current app. Use this, or you won't be able to upload in the store.
To see the package name is linked with your Firebase, open your project in Firebase and click on Settings, here you will see the package name of the app.
If is not the same:
-There, you can see an option to add a new app. Click the button and add a new app with your new package: com.pathapp
-Finally, you have to download the new google-services.json and add it in your project, deleting the old one if you still have it.
What is the mean of applicationId in build.gradle. and what is the difference between package name in manifest file and applicationId in build.gradle.
What is the mean of applicationId in build.gradle
Every Android app has a unique application ID that looks like a Java package name, such as com.nilu.myapp. This ID uniquely identifies your app on the device and in Google Play Store. If you want to upload a new version of your app, the application ID (and the certificate you sign it with) must be the same as the original APK—if you change the application ID, Google Play Store treats the APK as a completely different app. So once you publish your app, you should never change the application ID.
Read more about applicationId
what is the difference between package name in manifest file and applicationId in build.gradle
package specified in AndroidManifest.xml identify one application installed on the device
Read more from this answer and this also Package Name Vs Application ID
applicationId in build.gradle will overwrite the manifest file's package value. And in build.gradle file you can use productFlavors to define different flavors, and each flavor can have different applicationId.
productFlavors {
free {
applicationId "com.myapp.free"
}
paid {
applicationId "com.myapp.pro"
}
}
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
Is it possible to add Flavors to the new version of an already published App?
If yes, suppose the following senario:
I have a published app in Play Store (e.g. com.example.android). In the new version of the app I add (e.g. free and paid) Flavors. This addition changes the package name of the app to com.example.android.free and com.example.android.paid.
Suppose I publish only the com.example.android.free Flavor.
What will the link to the Play store be like?
https://play.google.com/store/apps/details?id=com.android.example (as it already was)
or it will be renamed to
https://play.google.com/store/apps/details?id=com.android.example.free
Just to be clear on the answer by marmor:
You CAN create flavours after you have a published application. But if you wish to keep the app published and updatable on Play Store that same app MUST have the original package name which means that it has to be one of the flavours created AND its package name left untouched.
As an example, imagine that you have one published app and then you decide that you want a FREE and a PRO version of it. You change your build.gradle file to have two flavours:
defaultConfig {
applicationId "com.mycompany.awesomeapp"
minSdkVersion 21
targetSdkVersion 26
versionCode 1
versionName "1.0"
}
flavorDimensions "feature"
productFlavors {
free{
}
pro{
applicationIdSuffix ".pro"
}
}
Now what this means is that the original app in the store is now the FREE product flavour and you can sign it and update it to the Play Store. You can even change its name. What matters is that its package name remains the same, in this case
com.mycompany.awesomeapp
which is the default defined and that uniquely identifies your app.
The PRO version is a different app now that you can publish and update as a new app. Its package name is now
com.mycompany.awesomeapp.pro
Meaning it is a new, different app, even though it shares some code base.
You can't change the package name of an already published app, you can however have two flavors free/paid, but one of them should have the original package name:
e.g.
free = com.example.android
paid = com.example.android.paid
which will mean the free app would update the currently existing one, and the paid app will be a new app on Google Play (with zero statistics and downloads).
the links to the 2 apps would be as expected:
https://play.google.com/store/apps/details?id=com.android.example
and
https://play.google.com/store/apps/details?id=com.android.example.paid
If you want to enjoy the best of both worlds, look into [in-app-billing][1] to allow your users to download the app for free, and pay within the app to unlock premium features.
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.