The API and implementation of NsdManager imply that a separate
Listener is to be used for each active registration or discovery
request. This isn't formally documented or properly enforced, and
weird and unpredictable things happen if an application uses a
Listener for more than one request at a time.
Update documentation to make this an explicit requirement.
Enforce the restriction when a new request is submitted for
processing; if the Listener is already being used to track an active
request, throw an exception.
Document the fact that apps should unregister services and cancel
service discoveries when the app is stopped (in KitKat and prior
releases, they'll leak if this isn't done.)
Re-order "release the Listener" operation to occur before the Listener
callback, so that the Listener can be reused by the application once
the callback has been entered - this eliminates a race condition.
Document this.
Pass 2: typos, added documentation about API level, changed to using
an explicitly defined return value for "busy listener".
Bug: 13512512
Change-Id: Ic164110759204b27d8a14376777b593ebe1865fa
- Improve wake lock work source updates to also update the current
history tag, in case the new work source gets recorded in the
history.
- Fix bug in recording radio active time that was not distributing
any time to apps.
- No longer hold a wake lock while dispatching data conn active call,
since it comes with its own timestamp.
- Fix issue where the top app was not being cleared while the screen
was off.
- Remove obsolete STATS_LAST stats type.
- Fix bug that was not clearing the total run time when resetting
the stats.
Change-Id: Iabe17a9edf34f762374ae09fcffb8a819cf72e30
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
Also add new API for determining whether the current data network
is active, and thus better scheduling network operations. This
API is designed to not be tied to a mobile network -- regardless
of the network, apps can use it to determine whether they should
initiate activity or wait. On non-mobile networks, it simply always
reports as the network being active.
This changed involved reworking how the idle timers are done so
that we only register an idle timer with the current default
network. This way, we can know whether we currently expect to
get callbacks about the network being active, or should just always
report that it is active. (Ultimately we need to be getting this
radio active data from the radio itself.)
Change-Id: Iaf6cc91a960d7542a70b72f87a7db26d12c4ea8e
We now compute radio active time per application, by distributing
the active time across all applications each time the radio goes
down, weighting it by the number of packets transferred.
Per-app radio power use is now computed using this radio active
time.
This also gives us a new metric "ms per packet", which give an
idea of how effectively an application is using the radio. This
is collected and reported as a new set of stats in the human-
readable checkin. (It can be computed from the raw checkin data).
Also improve sync reporting to include the sync source as used
in wake locks, not just the component name.
Change-Id: I0b0185fadd1e47ae749090ed36728ab78ac24c5e
This optimizes the path for battery stats to collect
per-uid network usage. It now collects wifi and mobile
usage separately, with a path that allows it to recycle
all data structures and filter out stats it isn't
interested in before they come back to java.
This is setting us up for the actual goal, to collect
mobile stats independently each time the mobile radio
goes down, allowing us to distribute mobile radio usage
across uids based on the number of packets they transferred
during a session.
Change-Id: I21a0f517cf087ea5aa8b8dd535e20b46e361a52b
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
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
