I created a .apk outside of eclipse using tiggr mobile (http://gotiggr.com)
i have the downloaded .apk and need to sign it - so i thought about running it through eclipse then signing it that way
im having the worse trouble importing it into eclipse.
does anyone have any other suggestions on signing this? i keep getting this message when uploading:
Market does not accept apks signed with the debug certificate. Create a new certificate that is valid for at least 50 years.
Market requires that the certificate used to sign the apk be valid until at least October 22, 2033. Create a new certificate.
Market requires the minSdkVersion to be set to a positive 32-bit integer in AndroidManifest.xml.
thanks for your help!
It would be faster to get the source code into eclipse via retyping it than to try and unsign and explode the apk, edit the manifest, fool the tools and sign the package. The tools can be run at the command line anyways and eclipse would just make it harder.
One problem you have is that there are problems in your manifest. The market requires some attributes set in it that you did not need while doing developer builds. You can open up the apk with anything that will open a zip file. You can edit text files with notepad. You package them up with ant by recreating the build.xml by hand. The instructions for signing things is here:
Android Dev-Guide: Signing your Applications
But what a LOT of work... and I am guessing you will need to do this multiple times just for one release to get the manifest right. Then what do you do when you need to update your program?
Will the service not let you export the code in an easy to use way (because... wow... talk about evil)? Failing that cut and paste will save you time but you will almost certainly want to have it in eclipse or some IDE ready to make changes for your market release and build, package and to sign it.
That's not your issue. I suppose you compiled your app and now you're trying to publish it in the market. To do that, you need a private key whick in turn requires you to have a android market developer account.
Normally you can develop your app and install it into most devices but you can't submit apps to android market without a developer account.
If what you really want is only to import your app to eclipse, I suggest you to create a brand new android project and copy everything into it. It's easier and faster than adjusting everything!
Related
I'm developing some changes for an app. It worked properly and compile fine before I configured a VPN (I think this may be related to the problem). Since that the aplication compiles fine but I can't update from previous versions to the new one (let's say from 1.0.0 to 1.0.1), an error message says "The package appears to be corrupt". The version number and code are updated.
I've found this, but it doesn't fix my problem: I've compiled in release and debbug.
It's documentated that the problem is related with the signing of an app in Xamarin because I can install the apk from scracth without updating, I've loaded the keystore again, check the path %AppLocalData%, configure again the path manually... nothing. Besides, the 'debbug.keystore' file doesn't open when the app is compiled, nevertheless it's open when I use the command in the document to load it again. I don't know if it should open, just saying. The key file is the same, nothing else changed.
Thank you for your help!
The debug.keystore is as the name suggests, only for debugging. It will differ between different machines you install Visual Studio.
Make your own keystore and save it somewhere secure. Especially if you plan to release the App in Play Store. If you misplace it, you will have a bunch of issues.
Creating your own keystore will also ensure the same and correct signature every time, and you can configure your project to use your own keystore instead of the debug.keystore that Xamarin.Android defaults to.
I made everything above again and it worked, not sure what was wrong. For those of you that may have a similar problem that's what I tried:
Check your keystore (it must be the same for different compilations) and store in a safe place as Cheesebaron says.
Check you have well configured the path for your keystore.
You may have a wrong enviroment variable if the step above fails (i.e. %AppLocalData% pointing to other location).
Check your version number. The number for a version must be higher than previous versions, you may use YYMMddXX (XX for differnet compilations in the same day)
If you altern to compile in release/debug, make sure your code doesn't affect the path to the keystore
Am having a bad time with android in order to create new release
i have created a Signed APK with two option
then i zipped the .apk file,after trying to upload it to google console am getting the below error
Your Instant App APKs do not declare a valid 'android:targetSandboxVersion' attribute in their AndroidManifest. Using the 'com.android.feature' Gradle plugin to build your Instant App would add this attribute automatically.
Note : the file zipped and all the solutions asking to zip the file, no luck :(
You need to be clear if you are producing an Instant App or a normal Android app. I think this is what is confusing you, or maybe you just aren't being clear in the question.
Android Instant Apps are special Android apps that launch from a web page, and don't need a user to install them. To build them you need the Instant Apps SDK, and to follow the development instructions here. Android Studio will produce a zip for you, you don't need to do it manually
For normal Android apps, you don't need to zip your APKs. Just upload the APK itself to the Play Console.
I think you are probably making a normal Android app, but because you are zipping it, the Play console thinks you are uploading an instant app. So stopping Zipping your APK, and just upload it to the Play Console as a ".apk" file.
While you are at it, I'd recommend using APK V2 signing - it gives much faster installation on modern devices.
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 am working on an android project. The project is shared through git. Each time I need to create a signed apk it's a hassle. The apk gets created but when I try to use the app, some file is always missing. Then I try disconnecting my local copy from the git sharing, then reconnecting, then rebasing, etc. Then it would create a good apk that works with no crash for supposed missing classes. (Note: the classes aren't really missing. They are classes I personally create inside the project)
My problem is, every time I need to create a signed apk, I have to emotionally gear up for a battle. And I have not figured out a repeatable process that is guaranteed to give me a good apk.
I only have this problem when exporting a signed apk. If I simply connect the device and build the code, that version of the app works. But that is not an exported apk, as it is using the debug key.
Does anyone know how to get exported apk to work with my git setup?
MORE DETAILS:
I am using
ADT eclipse
Egit
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.