"Uploaded a Debuggable APK" to Google Play - android

I am trying to upload the latest version bundle of an app that is already in the Google Play Console and I received this message:
You uploaded a debuggable APK or Android App Bundle.
I have not defined android:debuggable in AndroidManifest.xml.
If I try to define android:debuggable = "false" I get an error telling me that I should avoid hardcoding the debug mode as the system now assigns that as required.
How can I please both Android Studio and Google Play Console in their seemingly mixed messages?

It seems like you are uploading the debug variant of the app instead of the release one. Since the app you are uploading already has a previous version on Google Play, you will need to upload a release variant signed with the same key as the previous one.
Check if you have the following in your app level build.gradle
signingConfigs {
release {
storeFile file("...")
storePassword "..."
keyAlias "..."
keyPassword "..."
}
}
If it does, you can build the release variant by the command
./gradlew assembleRelease
If your build.gradle does not have the release signing config, then it must have been signed using Android Studio's "Generate Signed Build" option, and you will have to get the keystore file from the person who generated it in the first place.
You can read more about app signing here

The answer from #basilisk led me towards the solution by referring to the build.gradle file where debuggable true had been set for me. I changed this to debuggable false and the Console would now accept my app bundle without any warnings.
So in short check if debuggable is set in build.gradle as well as in AndroidManifest.xml.

Related

android signing with platform keys versus uploadkeys

I am developing for a closed platform and need to sign my apk with platform keys to be able to read from certain protected libraries. since this app additionally is not available on the Google Play store, does this mean that I don't need to sign with any other public private key pair for a release build? currently my workflow is such that we first create the build with gradlew assembleRelease which I assume uses the local.properties to sign my apk given the current build.gradle setup:
release {
keyAlias 'androiddebugkey'
keyPassword 'android'
storeFile file('./debug.keystore')
storePassword 'android'
}
if I am subsequently using apksigner to sign with the platform credentials, does that render the aforementioned release build.gradle config pointless?
So it looks like the gradle configuration is used for a particular build type, or the alternative is to use zipalign and apksigner on the apk generated from the gradle task. So if i wanted to continue using apksigner i should remove the build.gradle configuration. I guess theoretically it was signing again the app twice, but since the last one was the non-debug keys, it didn't really matter.
For reference:
https://developer.android.com/studio/build/building-cmdline#gradle_signing

Android app apk not getting installed from file filemanager

When I share my apk through Google Drive or any means App is not getting installed on some phones. But when I install it through ADB it is getting installed. What could be the problem?
there are many reason , maybe you use native code , or issue with signing.
try to install though ADB in release variant and check the error .
in android section at your app level gradle file "build.gradle module app add your signing config
.........
android {
signingConfigs {
config {
storeFile file('path to your keystore file')
storePassword 'keystorePassword'
keyAlias 'alias'
keyPassword 'aliesPassword'
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.config
}
}
.......
then from the left side click build variant and choose release
now run your app and you should get the same result as install the APK from file manager or what ever .
If you are using Android studio 3.0 above version and trying to build an APK then go to
Go to build
2: Build bundles
3: Build APK(s)
and then share the build. It will surely get installed in any devices.
Just make sure Device has allowed APK install from other resources.

Google Play Upload Failed 'You uploaded a debuggable APK'

I am running into the following message when attempting to upload my APK as an alpha release on Google Play.
'You uploaded a debuggable APK. For security reasons you need to disable debugging before it can be published in Google Play.'
In my gradle I have configured the signing config and build type(s) as follows:
signingConfigs {
release {
storeFile file("PATH TO KEY STORE")
storePassword "STORE PASSWORD"
keyAlias "ALIAS"
keyPassword "PASSWORD"
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.release
testCoverageEnabled true
debuggable false
}
debug { testCoverageEnabled true }
}
Furthermore, I've verified using jarsigner that my APK was signed and that the CN does not contain CN=Android Debug.
The manifest for the APK does not contain the attribute android:debuggable.
The application I've built is a Kotlin application with the following dependencies:
Android Support v13 27.0.2
Android Support Annotations 27.0.2
Android Support Constraint Layout 1.0.2
Junit 4.12
Mockito 2.15.0
Robolectric 3.7
Android Support Test Runner 1.0.1
Android Support Test Espresso Core 3.0.1
I've attempted to upload the APK generated via gradle command line (i.e., gradle build) as well as the APK generated from the IDE using Build, Generate
Signed APK, and I've ensured that the release variant is selected when building from the IDE and gradle before attempting to upload to Google Play.
Finally, I've attempted this with multiple keystores (creating a new one thinking that perhaps my first one was invalid), and still I cannot upload my APK. To clarify, this is the first apk upload. No prior version exists on Google Play.
Is one of the support libraries leading to this issue, or is there something I have missed?
I discovered the issue.
It seems an APK with test coverage enabled is considered debuggable.
After removing the line
testCoverageEnabled true
from my release build type, I was able to upload my APK.

Bamboo + Android + Gradle : how to produce signed apk?

Newbie with Bamboo trying to produce .apk for android application.
I have done the checkout and gradlew build tasks for default job, so the download and build process is fine.
What I need is to be able to produce signed .apk file and deliver it in someway to other part of our team.
Thinking about modify the gradle script to produce signed .apk with keystore/password and so, but not sure how to configure Bamboo to serve the .apk.
Any help much appreciated.
Building a signed APK is a function of your Gradle build script and not Bamboo. Based on the information available here, this is how I build a signed APK using Gradle. The information under the "Signing Your App in Android Studio" section is particularly helpful to create the keystore and the key necessary to sign the APK.
// APK signing configuration
android.signingConfigs {
MobileApp {
storeFile file("${rootDir}/TempKeyStore.jks")
storePassword "********"
keyAlias "********"
keyPassword "********"
}
}
// Build types - debug and release both use signing config above to
// sign the resultant APKs
android.buildTypes {
debug {
signingConfig android.signingConfigs.MobileApp
}
release {
signingConfig android.signingConfigs.MobileApp
}
}
Once you have your Gradle build script configured to build a signed APK, Bamboo can be easily configured to run your Gradle build script.

Android studio - release APK for flavor

I'm new to Android Studio and running a debug build on a device is working fine, however to test in app purchasing (and obviously to release) I need a release build signed with the normal key. I can make an APK using Build -> Generate signed APK, however the package name seems to be incorrect. Here's my build file:
apply plugin: 'android'
android {
compileSdkVersion 19
buildToolsVersion "19.0.1"
defaultConfig {
minSdkVersion 8
targetSdkVersion 9
testPackageName "com.company.common.common"
testInstrumentationRunner "android.common.InstrumentationTestRunner"
}
signingConfigs {
releaseConfig {
storeFile file("filname")
storePassword "password"
keyAlias "alias"
keyPassword "password"
}
}
buildTypes {
debug {
packageNameSuffix ".debug"
}
release {
runProguard false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
signingConfig signingConfigs.releaseConfig
}
}
productFlavors {
Flavor1 {
packageName "com.company.test"
}
}
}
dependencies {
// some dependencies
}
Note the package name overridden in the flavor. That flavor has no manifest; the only manifest is under main, and specifies a package of com.company.common. If I use Android to create a com.company.test APK and install it on a device, then generate an APK from Android Studio and install it, I end up with two apps on the device rather than the second replacing the first. This indicates that the package names are different, I assume because Android Studio is producing an APK with a package of com.company.common. Not sure how to verify that though.
When I just build the project, I get a debug APK but no release APK. How do I get a release APK with the correct package name? I just ran the app from Android Studio and it says it's installing com.company.test.debug, and that it needs to uninstall the app before installing. So now I'm thinking the generate signed APK generated a build with the debug package.
So far this is the issue that's preventing me from moving to Android Studio and gradle. Once I get past this I think I'm clear to move everything over so I'm hoping someone can help me figure it out!
Before you choose the Generate Signed APK option, go into the Build Variants window and choose the Release build variant. The Generate Signed APK command takes whatever the current build type is selected there and signs it. This obviously isn't what you want in this case; bug https://code.google.com/p/android/issues/detail?id=56532 is requesting improvements there.

Categories

Resources