My company is attempting to publish its first Android app on the market, and we have gotten to the code signing step. We have keys that we use for our other products and use the windows codesign tools to sign our products. We would like to use the same key to sign the Android app, but (obviously) cannot use the windows signing tool (because it only signs .dll's and .exe's)
Does anyone know how to sign an android app using existing keys? (.spc and .pvk files)
Thanks in advance.
You can try converting the PVK into something for the Java keystore. The odds of the resulting key being something the Android Market will accept is low -- for example, the Android Market requires the key to be good for at least 25 years, that you will use the same key for the entire lifetime of your app, etc.
Since the Android key can be self-signed, you are not saving any money this way and are only wasting time and increasing risk, IMHO.
Related
We're working on an app which needs to integrate with a specific hardware component.
Now, after an update on the side of the hardware vendor, they tell us we need to sign our APK with their .keystore (which they've provided, including a password) in order to work with their hardware.
I can confirm this approach works in debug mode, the APK is signed and we have access to the hardware. However this doesn't work with Google Play signing, because Google expects the APK to be signed with our uploading certificate (and signs the APK with the key stored on their systems afterwards).
This strikes me as a very strange approach, shouldn't the .keystore and password be kept private? And are we opening ourselves up to a massive security risk if we sign the app with their keys?
Any advice is much appreciated, thank you!
It is very unusual and a potential security risk to use the signing key and password which is provided by a third party.
But: Apps that are signed with the same key as the OS on an android device can get special permissions. This might be necessary to use hardware features and system APIs on an android device which are usually not available to normal apps through Android.
Besides that, when you setup Google Play app signing, you can provide your own signing key and password. This would allow you to use the key from your hardware partner in production Play Store apps.
I am a beginner solo game developer and I'm still learning about how everything works. I watched a tutorial series about making a game in Unity wherein they showed how to sign your App for Google Play. They implied that you make a new "Key" / "Alias" for every new game you make.
On the other hand someone else told me to make one Key-store and one Key and use that for all future apps.
My questions is should I make a new Key for every app, or should I make one Key and use that for all the apps I intend to upload to the Google Play Store?
You have to generate a .jks file (which is a key) and store it safely in drive. u need the key for further updating of the application.
And about your query, u need separate key for every different applications you develop.
To know more about signing applications.
Visit here for unity application signing
You have to create new key for every new App .Different Apps has to be signed with different keys.
Same key is used in case you want to update previous uploaded app in Playstore.
Link to official android documentation on app signing
I would:
Use Google Play App Signing
Opt to have a new key for every app
It doesn't matter too much if you share upload keys
Google Play app signing has lots of benefits, but two critical ones are it lets you use App Bundle which makes your download smaller, and if you ever lose your signing key (or have it compromised) it allows Google to help you. This is really useful for someone who isn't an expert in App Signing.
The benefit of having a different key per app might not be obvious to you. Suppose as a solo game developer your game makes it really big, and a large game studio wants to offer you a lot of money for it. Hooray, you've made it! But if you have the same signing key and keystore for all your games, then you have to transfer that key (and hence power over all your games) to the studio. If you have a different key for each game, then you can sell the one game they want to buy and hand over the key, but keep the separate keys for your other games.
Google Play App Signing does this for you by default. So I'd just use Google Play App Signing. But if you don't, I'd have a different keystore and key for each app/game.
Our company currently has several APPs for Android in Google Play Store, developed by different software providers.
What would be the best approach for this situation?
Having one keystore for all the APPs from our company?
Having one keystore for each provider? For each APP?
What would be the main benefits and drawbacks from each approach?
Thanks.
In my opinion having one keystore for each provider will be better approach in this situation. Afterall it is signing and instead of signing all the apps with one keystore, multiple signs will be better. However, if your company have 200 apps with 100 different provider then it would be unwise to have different keys. It is about your scale and choice. Yet, i don't think there will be so much difference between two approach.
You can use flavor for different-different app version and app.
I would STRONGLY recommend having a different certificate for each app.
I would also STRONGLY recommend using Google Play App Signing rather than signing the app yourself.
The benefits of the first case is future commercial flexibility. App developers often want to sell their app to another company, spin off a division to a separate company, or separate responsibility for app signing keys so they don't have a single point of failure. If you have a single key then:
If you sell the app to another company then you have to give them the signing key and they can sign any of your apps, thereby producing fake versions
if you want to spin out a division the same problem occurs
if you want one team to be able to sign their own app for testing, then they can sign any app for the company.
Having a separate key solves all these issues.
If you want to know why you should use Google Play app signing you should search StackOverflow for questions saying things like "help I have lost my signing key/password/had a computer stolen, what can I do?". There are hundreds of them, and the problem has hit even some of the biggest developers. If you use Google Play App Signing then Google Play will keep your key safe, and Google Play support can help you if you lose it.
To comment on the answer that cites the Android Studio page they misunderstand it. That is just about having a single signing key per app, not across apps.
There are some reasons to use the same signing key for multiple apps. On the Android system this gives the apps some abilities to trust each other in certain ways on things like RPCs, but it is very rare to need this.
I am concerned that users may reverse engineer my app, edit it, and publish it using the same SHA1 key. That way Google Play Games would verify the unofficial app and would make it able to post invalid scores to the leaderboard.
Is this possible?
SHA-1 is designed so that creating a different input (app in this example) with the same signature is VERY VERY difficult - Don't worry about that.
On the other hand, reverse engineering it and creating their own version with a different key would be much more feasible. I don't know how Google Play Games would handle that, but I suspect Google has planned for this situation.
Amazon's documentation is surprising lacking in information about the submitting binary process. From what I can tell, you submit an unsigned binary and they wrap it in their own code and produce a signed apk?
This leaves several questions:
Does the Amazon App Store perform a zipalign for you?
If you have your app in the Android Market (Google's) already, is it recommended to use the same package name or a different one? Does it make any difference?
I also saw elsewhere, that they offer the option to download the apk they prepare and sign it with your own key. Is it recommended to take this and then sign it with the same key you are using in the Android Market? Does it make any difference?
Are there any other considerations or pitfalls that one should know before diving into this process?
Yes. Amazon wraps your binary with code specific to their appstore that allows them to collect analytics data and enforce DRM. The app will be repackaged after that.
You should use the same package name. The Amazon distribution agreement currently has a number of provisos; e.g., that your app is not priced lower on another app store. They also do occasional checks to see whether the version of your app on the market is up to date. These checks are primarily done using the package name; changing the package name of your app could easily be viewed by them as a means to evade the terms of the agreement.
No. There may be good reasons why one would want to do this, but none that I can think of. By default, Amazon signs your apk with a signature that is specific to your Amazon developer account.
Other:
Read this. In particular, ensure that the app links correctly to the Amazon app store and not the Android market, or others. I don't have inside data, but I'd wager a fair amount that the vast majority of submissions that Amazon turn down fall afoul of that requirement.
Edit: Point 2 is no longer correct; see comment below.
Here is the reply I received from the amazon mobile app distribution team for a question concerning whether to submit signed or unsigned apk's:
"You can submit signed, or unsigned binaries to the store - we will then apply our signature to your app in either case. If you need to sign your app with a known signature (if you are using Facebook authorization for example) you can choose to upload your app using our self signing process (you will need to ask us for this to be enabled for you)."
The most straight forward way to submit an app is to export your signed apk from Eclipse (all zip aligned are ready to go), then upload via the Distribution Portal using our DRM and signature.
For the latest update of my app I just took the same signed apk I previously released to google play, and it worked well.
I have only published two little applications that sell almost nothing, but both got aproved and I followed exactly the same procedure I follow for publishing on the Android Market: I just exported the signed .apk from eclipse and also used the same package name. So far I have no problems, so I guess it's ok.
You should zipalign during every build, as a matter of practice.
I use the same exact build process for Amazon as I do before publishing to Google. Only difference is an Interface's variable to determine the market link (at build time, if/else is compiled out).