summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorAdam Powell <adamp@google.com>2016-01-12 10:11:42 -0800
committerAdam Powell <adamp@google.com>2016-01-12 10:26:16 -0800
commitd1d4d9cb3a2f40aa1a476b9e55c7a4981da21c0f (patch)
treed43eea7af9cd8c57901c800b24045d86b7e9b9a8 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent7c132d82c5600eb266a0121fe940cd8711a047e7 (diff)
Eagerly update fragment state when moving between states
As seen in frameworks/support! Previously we would not set a fragment's new state until the move to a new target state was fully complete. This causes problems when other parts of the fragment manager infrastructure (such as lazily initializing a child fragment manager) read that state while we're dispatching a state change call to a fragment. In this situation, adding a child fragment and then calling executePendingTransactions on the child FragmentManager would not have the intended effect, as the child FragmentManager would still be in state INITIALIZING. The expected lifecycle callbacks to the child fragment would then occur later. Fix this by updating the fragment state as we go through each phase of moveToState before we dispatch to the associated onState method, matching our usual pattern of invoking onFoo methods after foo has occurred. Delete the redundant resumed field as we now can use the state directly. Bug 25019275 Change-Id: I97fe45578d59ab643c9779eaeb475a331e446335
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions