apksigner fails to sign when keystore and key passwords differ and apksigner isn't explicitly told how to obtain the passwords [37134986]

Fixed

Bug

[AOSP] assigned

Status Update

No update yet.

Description

kl...@google.com

created issue #1

Feb 3, 2017 09:24PM

When apksigner is invoked without explicitly specifying how to obtain the keystore and key password, apksigner prompts for keystore password and uses that as the key password as well, making it impossible to use keystores where the keystore password differs from key password. A workaround is to explicitly tell apksigner how to obtain these two passwords. For example, --ks-pass=stdin --key-pass=stdin will force apksigner to prompt for keystore password and then prompt for key password.

STEPS TO REPRODUCE
1. Create a keystore where the keystore password is different from key password.
2. apksigner sign --ks keystore.jks some.apk

EXPECTED RESULTS
apksigner prompts for keystore password, then prompts for key password

ACTUAL RESULTS
apksigner prompts for keystore password, then fails claiming that it can't obtain the key because "Wrong password?"

Comments

kl...@google.com <kl...@google.com> #2Feb 15, 2017 08:36PM

I guess hidden should just be defined. Meaning, right now, hidden should just defined as "whether this fragment was hidden as part of a transaction". Hidden is not equivalent with visibility. I think that's where the confusion comes from.

kl...@google.com <kl...@google.com> #3Mar 7, 2017 05:28AM

We have passed this to the development team and will update this issue with more information as it becomes available.

kl...@google.com <kl...@google.com> #4Apr 24, 2017 06:23PM

Yeah, I'm seeing this issue as well, currently this is the workaround that I've come up with:

// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}

cb...@google.com <cb...@google.com> Apr 24, 2017 06:24PM

Marked as fixed.

ba...@gmail.com <ba...@gmail.com> #5May 7, 2017 02:23AM

@4 That actually won't technically fix as isHidden() will technically mismatch with the state passed into the child fragment. Each child fragment legitimately needs to have their state set to hidden.

pr...@gmail.com <pr...@gmail.com> #6May 24, 2017 04:12PM

Yeah, I realized that as I kept working further on it. Nevermind that solution, it doesn't work.

82...@gmail.com <82...@gmail.com> #7Jan 4, 2019 06:15PM

@6 I don't know what the ramifications are, but when you iterate, you can save the "currentState" and then hide them all via a transaction. When restoring to visible, restore to the original state.