I'm working on test Android app and can build it as 'release' and 'debug',
Development takes place on laptops with Android Studio,
Testing will be based on Crashlytics,
Production will be on GPlay.
Please advice what (and why) should I chose between 'release' and 'debug' for each environment?
Your Android app will execute in debug mode in your development environment, such as while installing an app from Eclipse or Android Studio IDEs and it will execute in release mode when installing from Google Play. In release mode any debug logging, StrictMode and the debugging option must be disabled.
Use 'release' build to publish your app to GooglePlay. The time it takes to execute the build will be bit longer than if you use the 'debug' build.
Use 'debug' to run your app locally and test your app.
Also, the release build has ProGuard (code shrinking) for detecting and removing unused code from your app.
Related
Over the weekend something happend, because on monday it wasn't possible anymore to make a signed production build of my App. The only thing that I installed was Ableton Live 11 but I don't see how this could be related. I use "Generate Signed Bundle / APK" to make sure the signingConfigs in build.gradle are not the problem.
When running from Android Studio it showed this:
When uploading the APK on APKPure it showed that the apk wasn't valid:
Steps that I've tried so far:
Tried different projects, all projects are unable to sign, so it's not the specific project.
Uninstalled Android Studio from this SO thread.
I've found the Signature mentioned on apkpure in google-services.json and I've deleted this, but same result.
You probably changed the KeyStore of your app.
Make sure that in build.gradle, the signingConfig-attribute of debug{} and release{} in buildTypes{} have the same value and debug{} has the attribute debuggable true
Source: https://stackoverflow.com/a/27873028
I have a problem with running Appium on my Android app. On release build, everything works fine. I'm able to run some basic test cases etc. The problem is when I switch from release to debug build. For debug, Appium is not able to open the app, there is a black screen and then error:
Exception in thread "main" org.openqa.selenium.NoSuchElementException: An element could not be located on the page using the given search parameters.
....
On emulator app is opened but this error still occurring with the same stack-trace (and again, release build works just fine)
I've tried already running my tests on different android versions (API 23, 24, 28) and results always the same.
I'm using AndroidDriver to find elements by id and click on them.
Is any reason why release builds works but debug not. Is there something I can do in order to run my tests on debug build?
Edit 1. My application is a Native Android app.
I'm not able to open the debug app with the Appium desktop (I just see the Android home screen because Appium is not able to run the app).
According to differences between debug and release:
release build (exact opposite for the debug build):
debuggable disabled
minify enabled
shrink resources enabled
proguard enabled
Plus release build is signed
I am new to android as well as android studio.
From my experience in visual studio, when we test the .exe in another machine we copy the release folder and .exe.
But in android studio I am seeing my colleagues test the debug apk by copying and deploying in other systems using USB drive. seems working also.
May I know what is the consequence of deploying that version? Is the release version relevant only for a play store purpose?
What is the technical difference/consequence other than that debug version contains debug information which may makes it slow or bulky?
Major differences are the debug flag and the signing keys:
For debug builds the apk will be signed with the default debug signing keys with debug flag enabled.
For release keys you will have to explicitly specify the keys to sign with and the debug flag will be turned off so that it cannot be debugged.
Proguard can be turned on for release builds. (also for debug builds but not advised). This step needs to be done explicitly and is false by default.
Note: these things can be altered in your build.config and you can choose what ever permutation and combination you wish.
One important difference is that release APKs typically have had ProGuard (code shrinking) run on them, which detects and removes unused code to reduce the APK size.
From Shrink Your Code and Resources:
Be aware that code shrinking slows down the build time, so you should avoid using it on your debug build if possible. However, it's important that you do enable code shrinking on your final APK used for testing, because it might introduce bugs if you do not sufficiently customize which code to keep.
Your colleagues are probably testing on the debug build type to save time, because it can take significantly longer to build the release APK as opposed to the debug APK.
The all above answers are correct BUT the major difference is that if we use the debug.apk to install the app on the device/emulator we can
*Debug it with debuuger
*Profile the cpu, memory, network with android studio profiler
*See the logs in the logcat
*Debug the layout with layout inspector
if use release.apk we can't use the above features, and we configure some features/libraries to work in specific out put type (Like we can use leakCanary only in debug apk)
The primary difference (if specified otherwise in the build.gradle) between a debug build and a release build is the key with which they are signed. Most app distribution channels would [only] want an app signed with a release key to authenticate the developer. Otherwise, there are no differences.
A release build may also trigger other options like code obfuscation and splits so, look out for these.
However, there are many changes that can be brought about in between these two versions. These should be specified in your build.gradle, if any. So, you should keep an eye there.
What are some notable differences that a developer should take note?
The first one is debuggable and the second one isn't.
That means that the first one will output all your Log.d's and the production version won't.
Also, by default, debug versions are compiled without ProGuard while production builds are compiled using the default ProGuard rules
you may take a look at those posts
Android Studio: Build type release /debug - what relevance does this have?
also the officiel documentation is clear and hepful
http://developer.android.com/tools/publishing/app-signing.html
hint
debug when you are working on the project
release when you are about to publish the app
good luck !
One of the most important differences is that debug version of app is not prguarded so it can be reverse engineered. The reason why it's not proguarded is because you can track your logcat outputs easily without need to check mapping files.
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.
Please explain the difference between Release vs Distribution modes when running a hybrid app project from Visual Studio for Apache CordovaIn Visual Studio, in Solution Configurations drop-down you have:
Debug
Release
Distribution
From what I can see "release" pushes the app to USB-connected Android device, while "distribution" only compiles it, and then just displays empty command prompt screen for adb.exe (but does not push the app to device).
I would like to test "distribution" version.
Thanks!
It's only for iOS apps. Before being submitted to the App Store, iOS apps have to be signed by a Distribution Certificate. The distribution configuration uses this Distribution Certificate instead of a Development Certificate which is used for debug and release builds.
The distribution configuration seems to have been removed in the recently released RC, with release taking its place. The documentation which previously stated:
When building a Debug or Release configuration, the Visual Studio remote agent selects the first valid iOS Development signing identity installed on your Mac.
When building a Distribution configuration, the Visual Studio remote agent selects the first valid iOS Distribution signing identity installed on your Mac.
now says:
When building a Debug configuration, by default the Visual Studio remote agent selects the first valid iOS Development signing identity installed on your Mac.
When building a Release configuration, by default the Visual Studio remote agent selects the first valid iOS Distribution signing identity installed on your Mac.