FYI, debug.keystore is in an undocumented Java format. There's a note here about it: https://github.com/golang/mobile/blob/master/cmd/gomobile/writer.go#L56

Why don't we shell out to keytool if user has SDK installed on their machine? If keytool is not on the PATH, we can fallback to the hardcoded key.

cc/ @hyangah

I have found the Android SDK does not put itself on the PATH, nor encourage users to set other environment variables. IDE-based projects expect to be used from inside IDEs. So how do you intend to find the tools on the average user's machine?

That said, keytool I believe is part of the JVM, not the Android SDK. It may well be common on the PATH of people with the SDK installed. (Or it may be inferable from some common Java environment variable.) So using it might well work, it just needs to be tried on a relatively light SDK setup.

keytool is a part of JDK. None of these details conflicts with my idea to fallback to the embedded key if we can't shell out and export. I would consider this as a workaround, we may recommend the user to have keytool in their PATH for debug.keystore support.

I'm OK with it if it is generally useful in the usual cases. That is, does the default install of Android Studio put keytool on the path on OS X, Linux, and Windows? Two out of three would be useful enough. If zero, it's not worthwhile. It's an empirical question.

I don't think Android Studio does anything with installation of keytool,
but Android Studio requires JDK, and JDK installation seems to place the
keytool in an easily discoverable place (e.g. /usr/bin in my case). The
default install of ubuntu doesn't seem to have it, but after apt-getting
open-jdk, i found it in /usr/bin. Given that the installation is not
painful, I think documentation mentioning the keytool is sufficient and
relying on keytool is okay.

2015-04-07 22:21 GMT-04:00 David Crawshaw notifications@github.com:

I'm OK with it if it is generally useful in the usual cases. That is, does
the default install of Android Studio put keytool on the path on OS X,
Linux, and Windows? Two out of three would be useful enough. If zero, it's
not worthwhile. It's an empirical question.

—
Reply to this email directly or view it on GitHub
#10090 (comment).

__

At what point in the documentation would this be mentioned? I'm trying to avoid "first, install java" as a development requirement for all-Go apps. (Because it will have to be followed with "second, uninstall the Ask toolbar".)

It should be mentioned in the lines of "if you already have a debug.keystore, we will use it" which already indicates that they have keytool on their machine. debug.keystore is generated by keytool. JDK is not a hard requirement, we will fallback to the embedded key.

You may argue that we should restrict the tool to the PEM keys. Apple distributes certificates as p12, the users will similarly need to convert them to PEM.

I am closing this issue in the favor of using a dummy key for development. We will introduce a flag to provide a PEM file for release builds. Or we might ask to user to provide the key from a known location such as ~/.gomobile/android.pem.

Both strategies seems to be applicable to the iOS release builds.