diff options
| author | Yohei Yukawa <yukawa@google.com> | 2016-03-16 17:22:22 -0700 |
|---|---|---|
| committer | Yohei Yukawa <yukawa@google.com> | 2016-03-16 17:22:22 -0700 |
| commit | 7b574cb8a1a3d0943392f2bf7180687eff8448ae (patch) | |
| tree | 9f9d28f75363978cec1cfa098149b20d82430c09 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | 13e22319e4d0bf24c3fd08649e180be648f28ad5 (diff) | |
Add more @NonNull/@Nullable to InputMethodSettings.
This follows up to a previous CL [1] for Bug 26279466.
It turns out that we have not clearly defined how nonexistent key should
be handled in InputMethodSettings#getEnabledInputMethodsStr(), e.g. it
returns "" for when mCopyOnWrite is true but returns null when
mCopyOnWrite is false.
Also, since InputMethodSettings now can revert changes made during
mCopyOnWrite is true, the caller may also start receiving null in the
following scenario.
1. call mSettings.switchCurrentUser(userId, true).
2. call mSettings.putEnabledInputMethodsStr(str) where str is non-null.
3. call mSettings.switchCurrentUser(userId, false).
4. call mSettings.getEnabledInputMethodsStr().
If the caller of getEnabledInputMethodsStr() has assumed that it would
never return null, then it would start crashing due to NPE.
With this CL, getEnabledInputMethodsStr() is marked to be @NonNull we
should no longer see such kind of NPE.
[1]: I9c6f9bb3d51174198e5f73588637f87ea0d90e11
68645a638ad1bfb734b2b0f56b17fe206bb891c5
Bug: 27687531
Change-Id: I169ad4957e68b65c64251b0849056195b8ca4911
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions