I just released my first Android Application through the market. I'm currently working on some new features for the next release and would like to install this "dev build" on my phone, without uninstalling the "production" version (among other things, this will stop future updates from the Market).
I'm especially interested in this because I'd like to give the APK to friends / "beta-testers" to try, but I don't want them to uninstall the released application first.
Is there anyway to have on one device two applications: "App (via market)" and "App (DEV)"
Would this involve using a different signing key or modifying the manifest in someway?
Thanks!
You can simply rename the package, so both apps are installed.
You need to change the package name in the manifest as well as in the source folder. Use Eclipse's refactoring for it and it will be done in a minute.
They don't need to be signed with the same key.
Using Gradle this is very easy. Here's an excerpt from one of my gradle files:
android {
// ...
defaultConfig {
resValue "string", "app_name", "<app name>"
// ...
}
buildTypes {
release {
// ...
}
debug {
resValue "string", "app_name", "<app name> (debug)"
applicationIdSuffix ".debug"
// ...
}
}
}
The key part for allowing another installation is using the applicationIdSuffix that is set in the debug build. Under the hood this basically does the same thing as proposed in Force's answer; it changes the application id of your app.
Setting the resValue app_name allows us to have different app names as well, this makes it much easier to keep track of which installation is which (since both application would get the same name otherwise).
Don't forget to remove the app_name from your strings.xml and fill in your own app name instead of <app name> if you decide to set the app_name in the gradle file like I did above.
Related
Is there a way to tell Android we are developing and testing the application locally ? so I can write something like that in the code to execute specific code that has to be executed in case of a local development vs when the application is intended to be deployed and fetch the right remote data :
if (LOCALLY) {
MyLocalTools.xdebugIntegration();
...
}
...
And when the application is to be shared, i just have to turn a global option to mute all the local code ?
If by "local development", you mean debug builds, and by "intended to be deployed", you mean release builds, you can use BuildConfig.BUILD_TYPE to distinguish those build types, or use BuildConfig.DEBUG to distinguish between builds that are debuggable versus those that are not. Or, if you need a particular constant, use buildConfigField to add that custom field to BuildConfig.
Product flavors, cited in another answer, are designed for cases where you need two separate release builds (e.g., one with Google's in-app purchasing APIs, one with Amazon's in-app purchasing APIs).
You can use build flavor and build variants.
In your build.gradle you can define some flavors like follows:
productFlavors {
dev {
buildConfigField "String", "SERVICE_URL_BASE", "\"dev.example/rest\""
applicationId "development.example.app"
}
prod {
buildConfigField "String", "SERVICE_URL_BASE", "\"prod.example/rest\""
applicationId "com.example.app"
}
}
As you can see we have defined 2 flavor with different variables to use. In my case I have defined two different endpoints for rest services and different application id.
Then on the bottom left of Android Studio you can select which build variant use to launch your app. Build variants are the union of build flavors and build types (defaults build types are debug and release).
In your code you can access variables defined in build.gradle file like follows:
BuildConfig.SERVICE_URL_BASE
And you can access your build type with of flavor with something like this:
BuildConfig.FLAVOR
BuildConfig.BUILD_TYPE
Using these variables you can implement all the switch you desire
I want to release my apk on play store. Initially I will release it on alpha, then beta and if everything goes well I will release it on production. Can we define different api endpoint for each in buildType inside gradle. if yes then how? As I just want to change the end point of API I am calling throughout my application. Like if I release my apk on alpha the api that it points will be http://test.alpha.bla.bla
for beta: http://test.beta.bla.bla
for production: http://test.production.bla.bla.
so in this my all version of app (alpha/beta/production) will be having same version code without any need to upload new apk.
Thanks.
I assume that you mean you want 3 different build targets (and thus 3 different uploads to google play):
in your build.gradle you have the android part, in there you can define productFlavors like the following:
productFlavors{
alpha{
buildConfigField 'string', 'server','http://test.alpha.bla.bla'
}
}
But you could also make enums and refere those (instead of the type "string" you would have to specifiy the full package name + enum type , and in the last part (the value), the full package name + enum )
you can then reference the server by using (in java)
BuildConfig.server; //this would be http://test.alpha.bla.bla
I would put it in strings.xml. Each build variant can have its own copy with a different value.
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.
I am developing an Android application that interacts with server via REST APIs. Obviously I need to use different URL for development and release builds. Commenting and un-commenting code is very tedious and error pron.
Which is the best way to handle this situation? Using different build types in gradle file is one which could automate the process, but I am not sure if this is the right way to go.
There is also a possibility of increase in number of build types viz. test, internal-release etc.
If you are using Android Studio, use buildConfigField to add custom fields to your BuildConfig class.
buildTypes {
debug {
buildConfigField "String", "SERVER_URL", '"http://test.this-is-so-fake.com"'
}
release {
buildConfigField "String", "SERVER_URL", '"http://prod.this-is-so-fake.com"'
}
mezzanine.initWith(buildTypes.release)
mezzanine {
buildConfigField "String", "SERVER_URL", '"http://stage.this-is-so-fake.com"'
}
}
Here, I have three build types: the standard debug and release, plus a custom mezzanine one. Each defines a SERVER_URL field on BuildConfig.
Then, in Java code, you just refer to BuildConfig.SERVER_URL. That field will have a value based on what build type you used to build that particular edition of the app.
It can be managed by using ProductFlavours in app build.gradle. ProductFlavours will manage different URL ie. development and release.
Please have a look it on medium.
It involves detailed explanation.
I had a similar issue and I solved it using
if (BuildConfig.DEBUG) { }
You will need to import
import com.commandsoftware.androidbookingapp.BuildConfig;
I had a similar problem with writing to logcat. I wanted to write all the messages if the app was signed with the debug key, otherwise write almost none of them. I solved the problem with this line of code:
boolean showAllMessages = ((getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0);
then using that boolean in my log writer. You should be able to do something similar when you initialize the URIs.
I am using Eclipse. I can't say with certainty that this will work in other IDE environments. This answer implies that it might be an Eclipse-only feature
I'm new to Android dev and I'm almost ready to release a first version of my app :)
While testing the signed release apk on my phone, it refuse to install because the debug version is installed with the debug signature.
So I have to uninstall the debug version but it delete all my database (and it will do it to my friends who are testing it).
Is there a way to manage a debug and a release version of the same app without losing data?
Many Android projects are starting to use the gradle build system (we transitioned to it when we started using Android Studio). Fortunately, gradle makes it really simple to install both a dev and release version simultaneously, each with their own independent data. The Android docs cover this, just add a applicationIdSuffix to your debug build type like so:
android {
buildTypes {
debug {
applicationIdSuffix ".debug"
}
}
}
I'm not aware of any easy way to do get around the uninstall/reinstall process, so your options include...
Buy a second device for testing (some Android devices are very cheap now, especially on eBay)
Use the emulator for testing
I see the same issue, but it's to be expected, so I use the phone for debug dev, and the tablet for production testing. When I'm close to a release, I test the production version on both devices and the emulator.
With your testers, I'd advise that you always give them release versions, but you could include extensive logging to help with problems. Debug versions are then only used by you, and release versions by them. If you provide testers with a release version, they use, and accumulate data, when they come to upgrade to the next version, the data can be retained (or updated, if you change the schema) to migrate their data.
I don't see a need for your testers to be using debug & release versions.
Thanks #Evan your solution works perfect:
android {
buildTypes {
debug {
applicationIdSuffix ".debug"
}
}
}
To append " (DEBUG)" to your app title when running in debug mode, place this code in your Activity's onCreate:
PackageInfo pInfo = getPackageManager().getPackageInfo(getPackageName(), 0);
//The .debug specified in gradle
if (pInfo.packageName.equals("YOUR_PACKAGE_NAME_HERE.debug")) {
setTitle(getTitle() + " (DEBUG)");
}
Why uninstall the app? Normally, installing the new version of the same app (identified by the package ID) retains all the app data.
EDIT: to retain app data by hand, copy it from /data/data/my.package.name/... to a safe place, then restore when necessary.
Configure the application id suffix
With the following configuration on your app build.gradle, the release variant will use com.example.myapp applicationId, and the debug variant com.example.myapp.debug
android {
defaultConfig {
applicationId "com.example.myapp"
...
}
...
}
buildTypes {
debug {
applicationIdSuffix ".debug"
...
}
release {
...
}
...
}
Configure multiple Firebase Accounts
If you use Firebase, you will need two Firebase accounts, one for production, and the other for development.
You have to configure Google Services JSONs for each account on its own variant source set:
The production google-services.json on the release source set: app/src/release/google-services.json
The development google-services.json on the release source set: app/src/debug/google-services.json
Providers authorities
If you have defined a provider in your AndroidManifest.xml, now you could have a conflict if both release and debug variants use the same provider authorities and you have both apps installed on the same device. To avoid this issue, a good practice is to use the applicationId as the authority suffix.
<provider
android:name="androidx.core.content.FileProvider"
android:authorities="${applicationId}.fileprovider"
android:exported="false"
android:grantUriPermissions="true">
</provider>
Custom icon for each variant
If you are going to install multiple variants on the same device, a good idea is to use different app icons, so you can identify them on the launcher.
You just need to design a debug app icon and locate it on src/debug/res/mipmap-xxhdpi-*
Configure FCM
Now that you use different Firebase Accounts, if you have an FCM (push) server, you will need to configure it with the correct credentials.
When a device with the debug app is registered, the FCM server needs to associate the registration token with the debug build type. So, when a push is sent, the token of the Firebase debug credentials is used.
So, you will need to send the build type to the FCM server, every time the app registers the FCM token.
The following article gives more info about this topic: Install your debug & release variants on the same device
For me, I also needed to add:
<permission
android:name="${applicationId}.permission.C2D_MESSAGE"
android:protectionLevel="signature" />
<uses-permission android:name="${applicationId}.permission.C2D_MESSAGE" />
Otherwise, both would receive the same C2D_MESSAGE permission which resulted in:
Failure [INSTALL_FAILED_DUPLICATE_PERMISSION perm=<your applicationId>.permission.C2D_MESSAGE pkg=<your applicationId>]