summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorYohei Yukawa <yukawa@google.com>2019-04-05 16:53:32 -0700
committerYohei Yukawa <yukawa@google.com>2019-04-05 16:53:32 -0700
commit17c1af439c04fb4591451bd7cf5abd7b42eb23cf (patch)
tree9a00b0b39a60a3f4fb5d27e8121c451fa48c5913 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent1ccf640d56159e33f6feb1d7ab49a4cdfa0a344e (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