I am getting the above error message when I try to debug an application that is already installed. Most others who run into this seem to be developing on different machines with different key files, but I am doing everything on the same box.
My issue is that I am testing my database upgrade process (i.e. what the onUpgrade() method of my SQLiteOpenHelper extension does). For this, I would like to try the upgrade on top of a variety of older builds. These builds are available as signed application packages. When I deploy such a package to a fresh emulator and then try to debug the current version on top, I get the error in the subject line. I think that this is because the debug deployment packages are unsigned, and the currently installed package is signed. Again, I know that the error goes away if I unstall the currently installed app, but then I cannot test the upgrade.
I do not want to go through the effort of switching back my dev environment to older build versions, so that I can build unsigned packages for these versions. I may not even be able to do this, because I switched source code repositories recently and lost some of the history.
I believe that if I were able to get Eclipse to generate a signed package for debugging, it should work. Alternatively, I could manually deploy a signed package and launch a debug session without a build/deployment step, but I have not been to figure out if this is possible, either. What can I do?
Edit: The Android documentation was helpful in figuring out how to sign a package with the debug key, but this does not help me, because I need to debug with a private key. I suppose that this is not possible.
You can sign current package with release key, install on device, run the application and connect debugger in Eclipse. How to connect debugger: in the DDMS perspective on the Devices view select your application and press button with "green bug":
I'll post it as an answer:
You should generate them all with one signature - otherwise it wont work. only uninstall and fresh install will work with different signatures. http://developer.android.com/guide/publishing/app-signing.html also taken from there:
Eclipse Users
If you are developing in Eclipse/ADT (and have set up Keytool and Jarsigner as described above in Basic Setup for Signing), signing in debug mode is enabled by default. When you run or debug your application, ADT signs the .apk with the debug certificate, runs zipalign on the package, then installs it on the selected emulator or connected device. No specific action on your part is needed, provided ADT has access to Keytool.
Related
I have the production release of my Google Play Store app on my phone and have an updated version of the app in Android Studio. I would like to test the upgrade process, but have run into a versioning problem, then a logging problem.
To get a "clean" install, I can go into my phone's settings Backup & reset > Automatic restore, turn that off, then de-install the app, and install it from the Play Store. Alternatively, I could download the production APK and install it from the adb command line (details below). The result is my device should be the same as a regular production user.
Not directly germane to the question, but to understand my motivation for watching the upgrade process is that the app has an SQLite database and I extend SQLiteOpenHelper, so onUpgrade() is called, and some database schema work is being done.
Update Incompatible
If I click the button to deploy the app, then select my connected device, it wants to uninstall before proceeding:
Installation failed with message Failed to finalize session : INSTALL_FAILED_UPDATE_INCOMPATIBLE
Obviously I could uninstall, but that would not test the upgrade process!
Generating Signed APK
I built a "release" APK, using Generate Signed APK..., which is the same process I use when generating a release for uploading to the Play Store. This gets around the versioning problem, but causes a logging visibility problem. The release configuration used in the past and now looks like this:
Installing APK to the device from Command Line
"C:\Program Files (x86)\HTC\HTC Sync Manager\HTC Sync\adb" install -r app-release.apk
The above did upgrade without uninstalling. The process I used was to open Terminal within Android Studio, change directory to where the generated APK was stored, then type the above command.
Logging / Debugging Problems
The adb command line triggered the upgrade process, but it did not start feeding the Logcat window immediately with debug information. I could connect to Logcat for all processes, but I could not get debug information for just my process, and did not have access to debugging tools.
Question
How can I start with a device that's running a signed production release then cause an updated version, contained in Android Studio, to run, without uninstalling, and with the ability to see the debugging output during the upgrade process? Or how can I modify a signed production release such that it allows an new version to update and allow debugging?
Because you're starting with an APK that is Debuggable=false, your work-around that includes building an update to the app using the same process as your production release process and getting a Logcat with all processes is probably the best you can do.
Rebuilding from Previous Source Control Version
One option would be to pull the specific version of the app out of your source control system and build it with Debuggable=true, and use that generated APK as your starting point instead of using the APK from the Play Store.
For the Future
Instead of making only one APK release version and uploading that to Play Store, make two versions. One version would be signed and uploaded as usual. And with the exact same source code, make another APK that has Debuggable=true. Rename each file with the version number. Then, later, if you ever want to try an upgrade from any version to any version, you can do that, and still have debugging capability.
I am developing an Android Application using Xamarin.Android in Xamarin Studio. It uses Google Play Game Services.
The project has run and tested find up until this point. Yesterday I upgraded my development PC from Windows 7 to Windows 8.1. In the process I also had to reinstall Xamarin Studio.
Now when my app attempts to connect to Google Play, it fails with error "RESULT_APP_MISCONFIGURED" which as far as I can tell means that my app is not properly authorized to access the Google Play API. However, nothing has actually changed.
I tested an older version of the app, and it is still able to connect to the Google Play API. Nothing in the code itself has changed, so I think it must be something to do with my recently upgrade of Windows, or the recent re-install of Xamarin Studio.
Any thoughts on what would help narrow down the problem? Is it possible the debug keystore has changed somehow?
An additional clue: when I attempt to build an deploy to a device that has the older, working version of the app on it, I get the following error:
Deployment failed because of an internal error: Failure
[INSTALL_FAILED_UPDATE_INCOMPATIBLE]
I then have to manually uninstall the old version before the new one can be deployed.
As has already been pointed out, the debug keystore won't be the same on all installations of Xamarin.Android. Which is expected behavior.
When using Play Services you want to create a keystore, preferably one for debug and one for release, or as different aliases in the same keystore (you figure that out).
Then you can make the build process automagically sign your app by adding some stuff to your .csproj file. You can read more about this in the docs.
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<AndroidKeyStore>True</AndroidKeyStore>
<AndroidSigningKeyStore>public.keystore</AndroidSigningKeyStore>
<AndroidSigningStorePass>MyKeystorePassword</AndroidSigningStorePass>
<AndroidSigningKeyAlias>MyKey</AndroidSigningKeyAlias>
<AndroidSigningKeyPass>MyKeyPassword</AndroidSigningKeyPass>
</PropertyGroup>
You can make a similar block for Debug as well choosing either another alias or another keystore.
Yes, debug keystore is part of the Xamarin installation and it changes if you reinstall Xamarin. You need to update the key signature on Google console, this time create a keystore and keep it hidden, keep it safe (so to speak).
I have been developing my app for a while and runing on a real device through Eclipse using Run As -> *Android Application*.
Now I am trying to distibute it to some beta users for the first time.
I used Eclipse to create a signed app, using a new keystore that I generated through the wizard. This appeared to work fine and when I check with Jarsign I get the message "Jar Verified", although there are a couple of warnings too. These are "This Jar contains entries whose certificate chain is not validated" and "Ths Jar contains signatures that do no include a timestamp".
I then copied the resulting apk onto the device and opened it. But got a message "This app was not installed". And in log cat I can see:
"Package has no certificates at entry ; Ignoring!"
I found some people had suggested going back to JDK 6 (I did have 7 previously), but that didn't help.
A few people suggested it might be due to duplicate activities in the manifest so I checked the manifest thoroughly.
What I have found is that if I rename the apk so that it is no longer exactly the same name as the last part of the package it suddenly works.
So if the package is com.mydomain.myapp and the apk is myapp.apk I get the error, but if it's myapp_debug.apk it installs just fine.
I find this very confusing and more than a little worrying. I would like to publish this app for real eventually and I'm not sure if I've done something wrong.
Based on your renaming makes it work description, you already have an app with the same package name installed on the device, but signed with a different certificate (probably the debug certificate used for eclipse-launch installs).
You must simply remove the existing installation before you install your release version. You can do that either from the settings menu, or with an ADB command of the form
adb uninstall your.package.name
Note that this removal will wipe out the private data stored by the app - that's part of why you have to do it, to prevent an imposter (naturally having a different certificate) from easily grabbing data left behind by a real app.
Remember also when distributing apps to others in this manner that they will need to allow unknown / non-market sources in their settings menu.
So this might sound like a complete and total noob question, but I'm going to ask and see what I find anyway.
I'm working on an Android application using Eclipse IDE. I have two development machines that I use (one for work, one for home) and one is 64bit while the other is 32bit. The phone that I'm using to test my application is a Google Nexus (Verizon flavored, most up to date drivers). If I build and run the application using one machine, then try to do the same on the other machine I get a console error that tells me to run an ADB command to uninstall my app because the signature has changed.
From what I understand it's because "debug.keystrore" (located in %USER_HOME%/.android) is different for each machine. Why does it do this? I assumed that the application signature was unique to the app not the app + dev machine. Is this normal behavior? If so, is there something I can do to get around it? I'm worried that copy/pasting the file between machines could cause problems, so I haven't tried it yet. Would I have to move this file every time I switch machines? Also, if I release my app into the wild; then loose my computer and have to start using a new computer (thus, changing the application sig) will everyone who installed my app have to uninstall the app because the application sig is different?
Bonus round: is there some way I can configure my IDE so that I don't have to change where eclipse looks to find the SDK every time I switch machines (i.e. make it look in both the ProgramFiles directory and the ProgramFiles (x86) directory.
To make sure the app was built by the same developer, Android wants the signature to be the same. Feel free to copy your debug key between machines. It has nothing to do with your machine or whether it's 32/64 bit; it only proves that you're the same developer.
When it comes time to release your app, you want to be very careful to
Keep your release key private, and
Keep your release key backed up in several places.
If you ever lose your release key, you won't be able to update your app, as you suspected.
Update: To make my answer more complete, it looks like the way to tell Eclipse which key to use is under Preferences -> Android -> Build.
I use Linux and don't use Eclipse; what I do is just copy ~/.android/debug.keystore from machine to machine, and the ant build tool uses it automatically, avoiding the pesky "certificates don't match" installation error.
For my release keystore, I have this line in my ant.properties:
key.store=../private/my-release-key.keystore
and keep my-release-key.keystore in a private repository much to the same effect.
I guess that for different platforms Google team has created different debug keys (I guess for tracking purposes). These debug keys do not depend on your application. If you want to distribute your application you need to create your own key. If you sign your application with your own certificate there should not be such kind of problem (because in this case, certificate depends only on attributes that you've entered when you create certificate). Under the Preferences -> Android -> Build you can select which keystore to use.
The signature is unique to each of the developers. From what I understand, if you are using the debug key, it uses your mac address or other unique characteristic to create an arbitrary key. So when you build and install your app onto a device with one machine, and then go to use another, you have different signatures, and thus your issue.
To be able to not have this issues, you should create your own key, as others have mentioned, and then use that to sign when you build.
You will NEVER want to release an app with your debug key, this is just for developing and when you go to release your app, you want to use your unique key that you created.
These keys are used to keep others from updating your apps, without your permission, so create a your own dev key and you won't have this issue.
Here is a link that should help you get started and pointed in the right direction: http://developer.android.com/tools/publishing/app-signing.html
I've copied "debug.keystore" from one machine to another, there are no ill side-effects. You can simply overwrite one with the other, and the un-install/re-install problem is fixed. The debug key is there only to protect the developer's own devices from other developer's binaries.
As others have mentioned, you do not publish your app with the debug key, you must make a release key and sign it, per the instructions on developer.android.com.
Also it's worth noting that the "debug" key is only valid for 1 year from the date it was created (when the SDK was installed). After a year, the SDK will say it's expired, and generate a new debug key. You'll have to re-copy the new key to the other machine, and you'll have to un-install the app signed with the old debug key.
As for the other problem you mention, you should have separate Eclipse workspaces that both reference the same Android project, using different SDK locations. The project does not need to be in a sub-folder of the workspace, so you can make this separation.
I create an APK and install it on the device. All works OK.
Then I try and run the app from Eclipse and it gives the error above. I didn't make any changes or even need recompiling. I tried running it as debug as well as release and both have the same errors.
Something is messed up somewhere as this used to work :(
EDIT: If I want to send out a pre release to users that have a normal install from the market, does that work ok, if I just send them the APK?
This happens when you for example install or run applications with the same package but signed with two different(may be debug) keys. Just uninstall the application and run it from Eclipse againg.
You should be able to uninstall the application (either though the Android App Manager or apk uninstall <application package-path>) and then deploy it. It seems to get confused when you do a proper install then try to deploy a dev build over it.
You may have messed up your debug certificate. Try to remove it from ~/.android/debug.keystore (Linux/Mac OS X); or %USERHOME%/.android on Windows.
then uninstall using adb your app : adb uninstall yourpackagename
And try to launch it again from eclipse.
It is neither necessary nor desirable to perfom an uninstall of the application if, say, you want to preserve user data like settings.
I have had the same problem for a while, and my solution is simply exporting the app (like when publishing, with the release key) and intalling that .apk file on my phone (I attach it to an e-mail and send it to myself).
This will have the same effect as updating it normally through Google Play Store, and all previously saved data is retained.
It may not be as convenient as running it directly from Eclipse, but having to uninstall the application all the time is not such a great solution either.