Fixed
Status Update
Comments
kl...@google.com <kl...@google.com> #2
Hi,
would you try to boot emulator with this command line flag:
-feature -Vulkan
and let us know if it fixes the issue for you? Also would you tell us what graphics card you are using and what is the graphics driver version?
would you try to boot emulator with this command line flag:
-feature -Vulkan
and let us know if it fixes the issue for you? Also would you tell us what graphics card you are using and what is the graphics driver version?
kl...@google.com <kl...@google.com> #3
The feature flag did solve the issue for me. Thank you very much. I don't use a dedicated graphics card. Only the internal one from the CPU.
kl...@google.com <kl...@google.com> #4
Your integrated GPU is supposed to support Vulkan 1.2. I would need more work to figure out why it crashes without that flag.
cb...@google.com <cb...@google.com>
as...@gmail.com <as...@gmail.com> #5
If there is more information that I can provide please let me know.
ap...@google.com <ap...@google.com> #6
Thanks. Would you help me to try some more runs to isolate the root cause? Please try to run the emulator with this flag:
-feature -GLDirectMem,-GLDMA,-GLDMA2
I am suspecting the Vulkan direct memory access and coherent mapping is causing the issue.
-feature -GLDirectMem,-GLDMA,-GLDMA2
I am suspecting the Vulkan direct memory access and coherent mapping is causing the issue.
ap...@google.com <ap...@google.com> #7
+cc rkir@
Description
For example, on Windows 10 with English US as the UI language, the console/stdin uses IMB437 as the character encoding. Assuming the six character password "ab¡äю1" (0x0061 0x0062 0x00a1 0x00e4 0x044e 0x0031 in big-endian hexadecimal representation):
$ keytool -genkey -v -keystore native.jks -keyalg RSA -keysize 2048 -validity 10000 -alias test
generates a keystore and key protected with 0x0061 0x0062 0x00ad 0x0084 0x003f 0x0031
whereas
$ keytool -genkey -v -keystore native.jks -keyalg RSA -keysize 2048 -validity 10000 -alias test -storepass ab¡äю1
generates a keystore and key protected with 0x0061 0x0062 0x00a1 0x00e4 0x003f 0x0031
The same command-lines on modern Linux/OSX which these days use UTF-8 by default for console produces keystores encrypted using:
0x0061 0x0062 0x00c2 0x00a1 0x00c3 0x00a4 0x00d1 0x008e 0x0031
and
0x0061 0x0062 0x00a1 0x00e4 0x044e 0x0031
respectively.
This weird behavior might be a remnant of the early days of Java where there was no Console (which automatically provides Unicode characters as input and thus has a concept of character encoding of standard input) nor a standard concept of character encoding for standard input. jarsigner appears to follow the same behavior, potentially to remain compatible with old keystores from those days and with current versions of keytool.
To complicate matters, keytool is not the only means of creating keystores which are used for signing APKs. For example, Android Studio offers this functionality as well. Thus, apksigner needs to try both the password represented as Unicode characters as well as the password represented as the form encoded according to the console's character encoding.