It's legal to call unlinkToDeath() *after* receiving binderDied(), as long as the recipient being unlinked was in fact linked previously. Don't throw an exception in this case. (The exception was going unhandled in the system process, bringing down the runtime. That's bad.) The change here is a bit subtle. In the new implementation, the lifetime of a JavaDeathRecipient -- the fundamental bridge between IBinder objects and the Dalvik/JNI world -- is tied to the lifetime of the Dalvik-side BinderProxy object it's associated with. That means it's inappropriate for the JavaDeathRecipient to disappear [for purposes of being referenced from the Dalvik side] just because the IBinder has sent out its obituaries, and instead the JavaDeathRecipient objects are kept around until the Dalvik-side client code actually drops its reference to the BinderProxy. This boils down to a one-line change: we no longer unpin the JavaDeathRecipients and free them immediately in response to binderDied(). The rest of the CL is #ifdefed-out debugging that is invaluable when bugs crop up. Bug 3513703 Change-Id: I743fa49669c9252f71dcabfd8dcf42ed729b70a5
…
…
…
Do not enforce the rule in MP3Extractor that all audio frames in an mp3 file must have the same mode
…
…
…
Description
No description provided
Languages
Java
77.3%
Kotlin
9.2%
PowerBuilder
6.6%
C++
5.5%
AIDL
1%