WifiManager: Remove static objects
Thanks to b/24334032, we know that there can be more than one
WifiManager object per process. Also, due to b/19159232 we know
that holding static references to contexts within WifiManager is
not okay. This CL addresses both issues by correctly implementing
Wifimanager as the per-context CachedService as it is instantiated
in SystemServiceRegistry.
To do this, all previously static object members of WifiManager
are converted to non-static. This is primarily safe since:
- In processes which only instantiated WifiManager from a single
context, the behavior is functionally identical between the
static and non-static implementation.
- In situations where multiple WifiManager objects were created,
this is not a real issue:
+ sListenerKey is okay to be tracked per-instance since it
only tracks replies for asynchronous outgoing calls for a
single WifiManager instance (replies are not multicast to
all instances within a pid, since replies from
WifiServiceImpl are addressed to the other end of the
AsyncConnection the request message came from).
+ The same is true of sListenerMap and sListenerMapLock
+ Having a per-WifiManager-instance mAsyncChannel is at worst
a small linear increase with the number of contexts that
use WifiManager, but for the vast majority of processes will
not be an increase at all.
+ Having a thread per WifiManager is something that has been
brought up in the past (b/25644527 comes to mind). I think
we should continue to track that particular problem there.
One static was added: an sServiceHandlerDispatchLock which ensures
that listeners from multiple ServiceHandler threads will be called
sequentially instead of interleaved. Since ServiceHandler was
previously static, this preserves the behavior where multiple
WifiManager objects would not deliver callbacks in parallel.
BUG=19159232
BUG=24334032
Change-Id: I24125a285f97e0c5b3ca4fd721ba8ed19aa245e9
1 file changed