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
When a client of the NsdService exits, NsdService should
clean up the requests it has sent to the mDNS daemon:
cancel any pending resource-discovery and resource-resolution
queries, and remove any services registered by this client.
If this isn't done, several bad things happen. The daemon will
continue to run unnecessarily, will report service discoveries
that can't be forwarded on to the client, and will continue to
advertise service ports for an application which is no longer
running until the device is rebooted (mDNS pollution).
Bug: 9801184
Change-Id: I0aa7311480322aefcff16f902fbbf34f50985d38
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
Change-Id: I40aabdfc65d86fdd0eaac7a1e7e56e6ff69796cf
Both requests are made using same id; and there is a chance that
stopResolve() is not fully completed when getAddrInfo() is issued. That
results getAddrInfo() failure, because both are using same requestId.
This change fixes this problem by creating a new unique id to call
getAddrInfo() with.
Bug: 11597153
Change-Id: I56bd78740e8a40bd31c52705dc797486aff53a50
Some services do periodic network time lookups and can wedge the other operations on
BackgroundThread and IO Thread, causing Watchdog to kill the runtime. So best to put
those handlers on separate threads.
Going forward, should convert NTP lookups to be async with callbacks.
Bug: 10646480
Change-Id: I8c7ba6052cb3539575712c2099a706b14ff60196
Some services do periodic network time lookups and can wedge the other operations on
BackgroundThread and IO Thread, causing Watchdog to kill the runtime. So best to put
those handlers on separate threads.
Going forward, should convert NTP lookups to be async with callbacks.
Bug: 10646480
Change-Id: I8c7ba6052cb3539575712c2099a706b14ff60196
netd now tracks statistics for tethered interfaces across tethering
sessions, so switch to asking for all tethering stats. (Currently
we're double-counting all tethering data, ever since it started
tracking across sessions.)
Also catch OOME to handle corrupt stats files, which we then dump to
DropBox and then start over.
Bug: 5868832, 9796109
Change-Id: I2eb2a1bf01b993dd198597d770fe0e022466c6b9
For now, this only tests network observers. It works by starting
NetworkManagementService with a fake netd socket, feeding it
inputs, and seeing if the appropriate observer methods are
called.
Bug: 10232006
Change-Id: I827681575642a4ee13ae48b81272521544b676bd
The default Alarm Manager behavior for KLP+ apps will be to aggressively
coalesce alarms, trading exact timeliness of delivery for minimizing the
number of alarm-delivery points, especially wakeup points.
There is new API in AlarmManager, setExact() and setExactRepeating(),
for use by apps that absolutely *must* get their alarms at a specific
point in time.
Bug 9532215
Change-Id: I40b4eea90220211cc958172d2629664b921ff051
When encountering corrupt stats, throw as IOException to allow
recovery at a higher level.
Bug: 9794832
Change-Id: I38d000b3bd8a4c99389c40a87ee0699efb6e9049
When encountering corrupt stats, throw as IOException to allow
recovery at a higher level.
Bug: 9794832
Change-Id: I38d000b3bd8a4c99389c40a87ee0699efb6e9049
The NPE happens because NSD Manager doesn't always notify with a 'good'
notification for SERVICE_FOUND. It can get in a situation where a
SERVICE_FOUND is recevied from MDnsDs demon when processing StopDiscovery
on the messaging thread. When that happens, NsdService sends a message
to NsdManager with an invalid index of the listener.
The fix is twofold. First, we fix NsdService to not generate a message if
it doesn't have a good listener index. And second, we also fix NsdManager
to watch for invalid index.
Change-Id: I3d63af10bded13c72e8e437a1ebf74a666760432
* commit 'd163b18c155aa5bf34730bdc2467d3e759b4a269':
Import translations. DO NOT MERGE
Do not allow 0 or smaller periodicity for syncs. b/9295383
Save Notification large icon to extras.
Workaround possible use after delete
Do not block notifications or toasts for SYSTEM_UID or PHONE_UID.
Don't orphan footers with transient state Bug #8725945
Avoid logging sensitive data.
When building commands to send across NativeDaemonConnector, scrub
sensitive arguments to prevent them from being logged.
Bug: 8609800
Change-Id: I84b16791749264a010f7e59f9918f68d71bac6b9
When building commands to send across NativeDaemonConnector, scrub
sensitive arguments to prevent them from being logged.
Bug: 8609800
Change-Id: I84b16791749264a010f7e59f9918f68d71bac6b9
This introduces four generic thread that services can
use in the system process:
- Background: part of the framework for all processes, for
work that is purely background (no timing constraint).
- UI: for time-critical display of UI.
- Foreground: normal foreground work.
- IO: performing IO operations.
I went through and moved services into these threads in the
places I felt relatively comfortable about understanding what
they are doing. There are still a bunch more we need to look
at -- lots of networking stuff left, 3 or so different native
daemon connectors which I didn't know how much would block,
audio stuff, etc.
Also updated Watchdog to be aware of and check these new
threads, with a new API for other threads to also participate
in this checking.
Change-Id: Ie2f11061cebde5f018d7383b3a910fbbd11d5e11
The NsdManager init was thinking it was done before the AsyncChannel
was fully setup and if the setup were slow and the app fast, the app
could make calls to the NsdManager that it wasn't ready for.
bug:8545006
Change-Id: I2cb2a7c0a1c7f3d2b81ac0f66d37346e6d2d720d
Usage is setMiracastMode(WifiP2pManager.MIRACAST_SOURCE) or
setMiracastMode(WifiP2pManager.MIRACAST_SINK) as an example.
Only available for internal use and can be called as long as
driver is active. P2p connection is not needed for it to be
called
Bug: 8493089
Change-Id: I1f87eaf3311212aae980077de26c05651a8cc811
