diff options
author | Yohei Yukawa <yukawa@google.com> | 2019-04-05 16:53:32 -0700 |
---|---|---|
committer | Yohei Yukawa <yukawa@google.com> | 2019-04-05 16:53:32 -0700 |
commit | 17c1af439c04fb4591451bd7cf5abd7b42eb23cf (patch) | |
tree | 9a00b0b39a60a3f4fb5d27e8121c451fa48c5913 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
parent | 1ccf640d56159e33f6feb1d7ab49a4cdfa0a344e (diff) |
Fix a bug in RegisterStatusBarResult parceling
This is a follow up CL to my previous CL [1], which introduced
RegisterStatusBarResult to consolidate return values from
StatusBarManagerService#registerStatusBar().
It turns out that the following fields are not correctly unmarshalled.
- RegisterStatusBarResult#mFullscreenStackBounds
- RegisterStatusBarResult#mDockedStackBounds
This is because those two fields were written with
Parcel#writeParcelable() while we were reading them directly with
Rect.CREATOR#createFromParcel(). Parcel#writeParcelable() needs to be
used with Parcel#readParcelable() for null handling and custom
class-loader handling.
With this CL, we now read/write these two fields with the following
methods, which can also be used to write/read Parcelable objects in a
bit more simpler style unless as long as we can rely on the default
class-loader.
- Parcel#writeTypedObject()
- Parcel#readTypedObject()
This CL also adds unit tests for StatusBarIcon and
RegisterStatusBarResult to make sure that these classes can be sent
over Parcel.
[1]: Ib1c0ae8f591ca09d0bce7a39f85ba57aad386e47
49efa718a86959e1fe996f05669c462c98f836f0
Bug: 122439339
Test: atest FrameworksCoreTests:StatusBarIconTest
Test: atest FrameworksCoreTests:RegisterStatusBarResultTest
Change-Id: I0f41cbcb4c2f1222f18e1e34e3cf40bb0dfdfdb3
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions