This is my first questions on SO, but I would first like to thank the community for helping me along the way in creating a few Android apps. I am not a programmer by profession, and most of the stuff I make is just for fun, but one Android app is a real project that I created for a client, and I've run into some real trouble and need some help.
The app I made basically takes in some data, stores it into an SQL database, and when necessary, uses queries to pull various information from the DB, and displays it. If any adjustments need to be made, I make them and just send them another .apk. No problem, until now...
I recently upgraded to Windows 10, doubled my laptop's RAM and replaced my hard drive with an SSD, and did a refresh of the OS. Everything, including Android Studio, runs like a dream now!!! I had a request from my client to make a few adjustments, so I recopied my backed up source code to my projects folder, opened the code, made the modifications, and resent the .apk to my client. They are getting the following message:
"X App not installed.
An existing package by the same name with a conflicting signature is already installed."
The only changes I made to the app were adding a table to the database (and upgrading the DB version number, of course), and modified some layouts and a couple of methods and calculations, etc. Nothing more. I have searched up and down and have even replicated the same error on my tablet and can't find a way around it. My client currently has a few months worth of data input into the app, so they can't just uninstall it and do a new app installation. Is there anything I can do at this point? Also, I never made any custom key signature, just programmed, made .apk, and have sent numerous updates without issue. Any help would be greatly appreciated. (I have all my project folders and .apks backed up for all the different versions that I have sent)
Thank you!
Your best bet at this point, assuming you can't find/get the original key, is to use a backup program (or adb pull worst case) to backup his /data/data/ folder. Then you can uninstall the original app and reinstall the new version. Then you can restore/adb push the old folder's contents to the phone to restore the data files. This may require rooting it.
If possible I would test this on another phone first, to make sure it works, since you only get 1 shot at this. I would also save your key in your source control repo in the future.
Related
I had an issue with my Computer and had to format it. An app was completely erased because my version control was only locally. The app exists on the Google Play store and I have access to the Android App Bundle. Is there a way to recover the flutter code?
sadly, practically: no... you may try to "decompile" APK (every "type" of abi/density/lang etc. splits), but still this will give you some Android-specified code, probably still messy, even without minifying. and you are seeking full flutter code, thats impossible
note that: if you could do that, got full code from "compiled" APK/bundle then anyone could do that, steal your code, make clones etc. this "possibility" would be just very unsecure
I compiled a project (that contains a sqlite db) using a pc that I have not access to that no more. People used that and inserted records to the db. I don't have any access to their tablets. I made a mistake and i have sent them the apk was in bin directory. I changed the program, I want to tell them to update their apps but when they try to replace app, android doesn't let them. So i have to sign my apk as same as the signature of the apk i made on that computer.
What should i do ? Thanks for your help.
Expanding on my comments:
There's not much you can really do if you don't have access to the old signature. It sounds like you're talking about the debug signature. As you found out, this varies from machine to machine, and if you don't have access to the old machine, it's just gone.
This is normally a good thing for security reasons. If it was possible to recover your key, anyone could do it. Then they could maliciously modify the app and upload it as a replacement.
As you've also found out, Android won't let you install an update that has a different signature than the currently installed version. If your users completely uninstall the app, they will then be able to install the new one. That's definitely inconvenient, and a customer service headache, but there's not any other way to do it.
Note that the users will lose any databases, etc, that they had in the app. It will act as a fresh install, since that's what it is.
Theoretically, rooted users could back up their old databases/preferences with any number of utilities and restore them later. In practice, even most users that can do this won't bother with it.
I know there are plenty of questions about this on here, but I've tried everything (but the correct 'thing', obviously!) and nothing seems to shine any light on the problem I'm having.
I've written an app (for a customer), which is designed to be hosted on their own server. The app references a simple text file with the latest version code in it and checks it against it's own version. If it's out of date it goes off and downloads the update. Everything is working as intended up to this point.
I use the:
Intent i = new Intent(Intent.ACTION_VIEW);
i.setDataAndType(Uri.fromFile(outputFile), "application/vnd.android.package-archive");
i.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(i);
...code to start the install process of the newly downloaded .apk file. And that all starts as I would expect.
I click on "Install" - when I'm prompted to confirm the overwriting of the current app, with the new. It starts, and then displays:
App not installed. And existing package by the same name with a conflicting signature is already installed.
Now I'm aware that Android can't have multiple applications sharing the same package name, which is fine, but nothing comes up in LogCat and I can only assume that the OS is annoyed at me attempting to 'update' my app, even though I'm going through all the correct channels and using the inbuilt package manager to do it for me!
Can anyone tell me what the OS is moaning about? I'm not attempting to install two apps side by side, I want it to update it, which it starts to do, and then gets really confused.
Is it something to do with me using the same keystore for signing the packages? I highly doubt it as I've used the same keystores previously to handle updates to games and the like, but I just can't figure out what it's complaining about.
Hopefully someone out there has had this issue and solved it, and can point me in the right direction. I'm flying a bit blind with the limited information it's giving me :(
Cheers.
You have built the new and old versions using different signing keys; likely you either built them on different machines, or one is a debug certificate and the other a release one. When this happens, you typically have to manually and explicitly remove the old version before installing a new one with a different certificate - it's basically a safety measure against inadvertently installing a trojanized imposter update.
Note that you can move certificates between build machines (and may have to if you turn the codebase over to the customer), though you will want to be careful when doing so.
I was wondering if it's even possible. Let's say I separated my app into "Library loader" and "Library" where library piece can be downloaded by "Library loader" from my server.
This way I don't need to rely on users to install updates to my app.
I understand it's probably not possible, but stillw wonder what you all know :)
This is internal business app and updates always pain. I do throw notifications to user, etc and there is still problem forcing user to upgrade.
Yes, I believe this is possible. Swype / the Swype Installer work this way. You might investigate it.
From what I remember:
You install the Swype Installer from an APK, then run it.
The installer downloads the Swype APK, and chaperones you through the system dialogs to install and enable Swype.
When Swype decides your beta key has expired, or whatever, it disables itself and then you use the installer to update.
This isn't dynamic linking at all though but it is a system to support forced updates.
Update:
Blog post from Google talks about dynamic class loading here:
http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FhsDu+%28Android+Developers+Blog%29
Possibly, and if you have root access, certainly, although what I'm thinking of would require the NDK. When you load data with the NDK, it is done dynamically. So if you replace that library, it would obviously update the functionality.
However, I do see many possible issues with this. The largest of which is I'm not sure if you have write access to where your library is stored (once the app is installed anyway). But I'm not sure of this. The folder is /data/data/(package name)/lib. I do know you have some limited access to the parent of that folder though (as that's where your database is stored).
For the next version of our application, I want to change the sharedUserId since we now use an internal control dashboard app which must write to the other app's settings files.
But since the app is already installed on many phones, will this be a problem? I ran a little test on the emulator, and I'm seeing exceptions in the device logs that *.bak versions of the preference files cannot be written. Not sure how critical that is. Curiously, safing settings still seems to work, even though the shared_prefs folder had been created using another Linux user ID.
Did anyone try this before?
And to answer my own question again:
No, it's not safe. Since updating an app via Android Market will not remove the database and preference files, the new version will not be able to read or write these files (since they were created under a different Linux user ID), and the app will crash after the update. You would have to ask your users to completely uninstall and reinstall the app, which is certainly not recommended.
As a general rule I conclude from this:
Whenever you start out developing a new app, make sure to set a manual android:process and android:sharedUserId attribute! It doesn't hurt in case you don't need it, but it gives you full control over which apps have access to this app's private resources.
No solution as of now, but starring at registered issues might get Google to fix this:
http://code.google.com/p/android/issues/detail?id=1227
http://code.google.com/p/android/issues/detail?id=14074