i am trying to implement the force update feature using app center, i have followed their documentation found here and it doesnt seem to work at all
here's the code inside the App Class
AppCenter.start(
getApplication(), {APP SECRET HERE}, Crashes::class.java,
Distribute::class.java, Analytics::class.java
)
and i have tried uploading a build like this then downloading first, and after that i uploaded a newer version with higher version code / version name and set the checkbox for "Mandatory Update", i don't get any prompt at all to update when i start the app then.
Found the problem with the appcenter force update, AppCenter Distribute will not work on release mode if debuggable in gradle is set to true.
so make sure to leave it on false at the build type you will be testing on
debuggable false
adding this line before starting AppCenter showed me the logs that clued me to this.
AppCenter.setLogLevel(Log.VERBOSE)
I am trying to launch my application in debug mode by using the little debug icon on the right of the run icon. i assumed this is the way to start debug mode.
The problem is that i am checking BuildConfig.DEBUG to see if i am in debug mode but it's always true and when i want to check in generated build.config file i found : public static final boolean DEBUG = Boolean.parseBoolean("true");
My question is : am i doing something wrong in launching debug? is it not the way we do it? how can i use debug mode?
You're confusing debugging with a debug build.
BuildConfig.DEBUG is an indication of whether or not your app is a debug build or a release build, it doesn't have anything to do with launching the app to debug. Even launching the app by just running it will also have BuildConfig.DEBUG as true, because it's still a debug build, this will only change once you actually create a signed release.
The icon you're referring to attaches the android debugger to the process, allowing you to use breakpoints, but it generates the same output as it would by simply running the app as well.
BuildConfig.DEBUG will only be false once you create a signed release build, so it has nothing to do with launching the app to debug
Thanks to Adam Burley's comment that lead me to figure out why my build always had BuildConfig.DEBUG = true, even when doing a signed release build.
If you have either of the following set for a buildType in your build.gradle:
testCoverageEnabled true
debuggable true
Then your DEBUG value will be true for that buildType, no matter if it's a signed release build or not.
I am trying to run my android application on other devices, it installed properly but some XML file not working properly. It works as I expected when I installed through USB debugging. I am trying to find solution for many days. I don't get anything related to my issue.
This must be the result of Obfuscation
Add this lines in your build.gradle
buildTypes {
release {
...
debuggable false
shrinkResources false
minifyEnabled false
...
}
}
or you can add your files in pro-gaurd
I'm looking for a way to tell if my app is running under the debugger or running "normally", under Android Studio..
These two cases are
1. Run the app by clicking the "Run app" button (green arrow)
2. Run the app by clicking the "Debug app" button (gear icon)
I would like to output more verbose diagnostics (using Log.*) while debugging.
I tried checking BuildConfig.DEBUG but that is TRUE in either case. I suspect this is because Android Studio signs the app with the Debug Certificate in both cases.
Does anyone know how to distinguish these two cases at runtime?
typically one would check for BuildConfig.DEBUG (or a boolean variable holding it) and then log:
if(BuildConfig.DEBUG) {Log.d("SomeActivity", "debug message");}
see the documentation... most relevant for debugging is build-config debuggable true/false.
the run button does not start the debugger; no matter the build-config (it just skips all breakpoints).
in multi-module projects, one should check with:
(getContext().getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0
to tell them apart, two build types need to be configured:
android {
...
buildTypes {
debug {
...
renderscriptDebuggable true
jniDebuggable true
debuggable true
}
release {
...
renderscriptDebuggable false
jniDebuggable false
debuggable false
}
}
}
and to precisely answer the question, there even is one method called isDebuggerConnected(), which would always return false when hitting the run button (no matter the build-config).
"Run app"
This will install the application into your device/emulator
"Debug app"
This will enable you to debug function by placing the break points into your code.
which means you will be able to stop execution of code at that point and debug it line by line. To know more about debugging in android see this
Both the application are debug applications.
To know more about build type please read this
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>]