4846fff84d
When NetworkRequestInfo#binderDied is called in ConnectivityService, only pass the NRI to handleRemoveNetworkRequest. This is to prevent a potential crash when unlinkDeathRecipient is called twice for the same NRI. Also, as a cleanup, don't iterate mRequests in the log message on binderDied. As per the bug, the chain of events leading to a potential crash are: - `Connectivity.NetworkRequestInfo#binderDied()` is called for an NRI tracking multiple `NetworkRequest` items. This can happen for a TRACK_DEFAULT request filed by a UID on a different preference than the default, which copies the request list. - This in turn triggers multiple `EVENT_RELEASE_NETWORK_REQUEST` events for the same NRI, one for reach `NetworkRequest` tracked. - When handling `EVENT_RELEASE_NETWORK_REQUEST`, each `NetworkRequest` that is passed in will then be used to look up the parent NRI that originally sent it to be released. - Therefore if an NRI was tracking three requests, it would trigger three release network events, then each request would be used to look up the same NRI again when handling said release event. - Finally, `ConnectivityService.NetworkRequestInfo#unlinkDeathRecipient` is called for the NRI in question. Using the scenario above, that means we could call `unlinkDeathRecipient` multiple times for the same NRI if it was tracking multiple network requests causing the associated crash. - If `unlinkDeathRecipient` is called more than once for the same NRI, it will cause the crash listed in this bug. - The fix is to only call handleRemoveNetworkRequest for the NRI once. This works since when removing the NRI, we iterate over all of its requests to remove them. By only calling handleRemoveNetworkRequest once, it's ensured `unlinkDeathRecipient` for this NRI as part of `Connectivity.NetworkRequestInfo#binderDied()` is only called once and not potentially multiple times. Bug: 185541983 Change-Id: I918c8620f2975d810894c178277771764923b5a4 Test: atest FrameworksNetTests Merged-In: I2a2ad4ec6d415423182a1856a898779203658f8b