Fixed
Status Update
Comments
kl...@google.com <kl...@google.com> #2
These changes would be really nice! Being able to change the text colour is really important as it now doesn't match the rest of our app either.
Stack overflow posting -http://stackoverflow.com/questions/32533069/how-to-change-a-title-color-in-chrome-custom-tabs
Stack overflow posting -
kl...@google.com <kl...@google.com> #3
Changing text color and the overflow icon color is important to us too! Awesome work on the feature though.
kl...@google.com <kl...@google.com> #4
The ability of customize the status bar color is very important!
cb...@google.com <cb...@google.com>
as...@gmail.com <as...@gmail.com> #5
It is in the essence of a "custom" UI component to have a custom color. Please add this feature!
ap...@google.com <ap...@google.com> #6
I have noted that the status bar automatically generated from the toolbar color is a bit darker than needed. The status bar color of the chrome activity is different to the one of the rest of my app. It doesn't strictly follow Material guidelines.
ap...@google.com <ap...@google.com> #7
The same issue I met. And is there a way to customize the title? using my own title rather than the url's. Thanks
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.