Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
Building note: run ./gradlew ... -x processReleaseMetadata
jb...@google.com <jb...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 5f6e46e40a7e47924ac1d04426230466de7b6f38
Author: Sergey Vasilinets <sergeyv@google.com>
Date: Tue Aug 07 15:57:10 2018
Fix ViewModel proguard rules
It removes allowshrinking modifier: a constructor
shouldn't be removed if it is unused, because it is
called through reflection
Test: manual =\
bug: 112230489
Change-Id: I215fe895fa12eb04172e9380a296e2d74567907c
M lifecycle/viewmodel/proguard-rules.pro
https://android-review.googlesource.com/727573
https://goto.google.com/android-sha1/5f6e46e40a7e47924ac1d04426230466de7b6f38
Branch: androidx-master-dev
commit 5f6e46e40a7e47924ac1d04426230466de7b6f38
Author: Sergey Vasilinets <sergeyv@google.com>
Date: Tue Aug 07 15:57:10 2018
Fix ViewModel proguard rules
It removes allowshrinking modifier: a constructor
shouldn't be removed if it is unused, because it is
called through reflection
Test: manual =\
bug: 112230489
Change-Id: I215fe895fa12eb04172e9380a296e2d74567907c
M lifecycle/viewmodel/proguard-rules.pro
pe...@gmail.com <pe...@gmail.com> #4
Thanks!
jb...@google.com <jb...@google.com> #5
I had the similar problem. Hoping the problem will be fixed in the next release. Thank team!
ba...@gmail.com <ba...@gmail.com> #6
it will be part of rc02
ba...@gmail.com <ba...@gmail.com> #7
When will rc02 be released?
wa...@gmail.com <wa...@gmail.com> #10
Well, it wasn't released properly.
re...@gmail.com <re...@gmail.com> #11
They updated version 2.0.0 in the today so I can update my app for now :D. Thanks!
ku...@gmail.com <ku...@gmail.com> #12
Comment has been deleted.
ow...@gmail.com <ow...@gmail.com> #13
Hi want to play
jb...@google.com <jb...@google.com> #14
Alluda
Description
Much like was done for Fragments in b/162255449 , When using the ActivityResultRegistry with a
LifecycleOwner
, the latest possible time thatregister()
should be called is while the lifecycle is CREATED. This ensures that any registered callbacks are always registered in the same exact order.If there is an attempt to register after the
LifecycleOwner
is STARTED, we should throw.This is different from b/162255449 because fragments don't move their Lifecycle until after their lifecycle callbacks (another joy of the multiple fragment lifecycles). Once b/127528777 is fixed, this will go for fragments as well.