Due to race conditions or programming errors, the NsdManager can attempt to process an asynchronous status message (and issue a callback to the listener) after the listener has already been removed from the NsdManager state. This causes dereferencing of null objects, and a crash. Split out the three async-queue message cases: these are ones in which message.arg2 does not hold an NsdManager array index and the code should not interpret this field as if it were. Add an explicit check for "null listener" (the array index in the message has already been released), log a warning, and exit early. Safeguard accesses to the "NSD service type" string from a possibly null) NsdServiceInfo object... return a constant "?" string rather than crashing. Bug: 9016259 Manual cherrypick of commit b1fbb14122a99c62363a949dd634294f5e887ef, change-ID I7a6ff6842cf035cefbafe2a023ae1fd43734081e in master. Change-Id: I8d9b7a1763d47d061a0f46b3cb453de4bdb8c2ed
cherrypick from ics-mr1 docs: source for nw app Change-Id: If50f407a0e56fa802fe9beedaa650e3a131872b2
…
Description
No description provided
Languages
Java
77.3%
Kotlin
9.2%
PowerBuilder
6.6%
C++
5.5%
AIDL
1%