Request system fatal crash via SysRq when a watchdog timeout loop is
detected. This escapes automatically the device hanging symptom and also
preserves context of system server in memory snapshot.
More details and background: go/break-sys-watchdog-loop
Bug: 141948707
Test: Insert 'sleep_forever()' to block BinderThreadMonitor to reproduce
watchdog timeout.
Change-Id: I3ae4b33b0d7811764c61663ac3718311b55fd048
The test had TODOs to address to use IpUtils and NetworkStackConstants
classes once they were moved to frameworks/libs/net. This is now done,
so using the new classes.
Bug: 158042941
Test: atest TetheringPrivilegedTests
Change-Id: I536b4506dbc3b42547ba9cb4e7c3c7a3e9459dd1
This reverts commit ae03031efe.
Reason for revert: Merge the reverted patch by accident.
Bug: 162627132
Change-Id: Ic2f072730050cb47926cec6ed24af7ef9e5e7055
Expose the MmTelCapabilities#isCapable() API to complete
a chain of APIs exposed for debuggability in Android RVC.
Without this API, there is no (public) way for a caller that
receives a capability callback to determine whether a particular
MMTel feature is enabled for a particular IMS Connection.
Bug: 156107100
Test: make update-api && make offline-sdk-docs && make
Test: cts - ImsServiceTest#testCapabilityStatusCallback()
Merged-In: I0a0d72897112460370e6981ae33cef4da6e3ce4b
Change-Id: I0a0d72897112460370e6981ae33cef4da6e3ce4b
(cherry picked from commit 21157d56a9)
The official API differences report is not produced from the
artifacts this rule creates, but by manually running metalava
with the right txt files.
As there are no other known users of these jdiff files, remove them
for now.
Bug: 158465496
Test: m
Change-Id: Iee9dd1a5d5543f3f629e3631c8224e6bfe4dddcb
Currently, NetworkStatsSubscriptionsMonitor will skip the
listener registration until the IMSI is available to deal
with SIM PIN locked case. However, this solution can only
handle the case that IMSI changes from/to null. And it also
relies on the assumption that IMSI never changes for a subId.
Thus, support dynamically update IMSI to handle IMSI changes
more robustly.
This patch also address leftover comments at ag/12400327.
Test: enable SIM PIN and manually test
Test: atest NetworkStatsSubscriptionsMonitorTest#testSubscriberIdUnavailable
Test: atest NetworkStatsSubscriptionsMonitorTest#testSubscriberIdChanged
Test: ./out/host/linux-x86/bin/statsd_testdrive 10082
Bug: 160941101
Change-Id: I625a5b10ee4806f6fee99c2d9d6c5e7977ff785e
The contentprovider's callback 'onChange(...)' is asynchronous.
If one app set the 'screen_brightness' provider frequently over a period of time,
the contentprovider's 'onChange(...)' can't stop, just like 'Self-exciting oscillation'.
So, We need remove handler's messages before send.
Test: build pass, feature pass.
TestCase: set the 'screen_brightness' provider frequently, can use a
loop: for(i=0;i<1000;i++){put(...)}.
Signed-off-by: yangyankai1 <yangyankai1@xiaomi.com>
Change-Id: I346696c69623829d4dda372edaf35b6e3f147780
It is possible that an app which is in fg-service process state to be
considered idle. Since we don't want to block connectivity of apps in
the foreground state, we should check the uid process state in addition
to its idle state when deciding whether to block its network or not.
Test: atest com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testAppIdleMetered_enabled
Signed-off-by: xiamengsen <xiamengsen@xiaomi.com>
Change-Id: If7e42605eb162abf6f88f03f28f7245659a7748c
New config_sms_ask_every_time_support indicates whether it supports
"Ask every time" for sms.
Test: build
Signed-off-by: Taesu Lee <taesu82.lee@samsung.com>
Change-Id: Ic7b123bced6cd741538f7c412d2b236cdce41c14
Anomaly alarms now rely on the flow of events into statsd's socket for
firing alarms. Remove the StatsCompanionService code path, which is
unused now.
Test: m
Bug: 161326200
Bug: 152642091
Change-Id: Ife0b17c281984fc489ef46039cbf5aa7b1346bdb
Merged-In: Ife0b17c281984fc489ef46039cbf5aa7b1346bdb
Anomaly alarms, which are used for prediction-base duration metric
anomaly detection, currently use alarm manager for setting alarms. This
can result in excessive binder calls to SCS to set/cancel the alarms if
the duration metric that the alarm is based on gets stopped/started in
quick succession.
To resolve this without losing precision, we can instead rely on the
flow of events into the statsd socket for this prediction. The socket
receives events very frequently, so there should be minimal (if any)
loss of precision, and we can remove the binder call entirely.
One concern is that we used to hold a wakelock when the alarm fired
(since alarm manager would hold a wakelock), and we now lose this
ability.
Test: atest statsd_test
Test: atest AnomalyDetectionTests
Bug: 161326200
Bug: 152642091
Change-Id: If37e5c6ccd8efa4e822c70a0444fa6b5a31bebca
Merged-In: If37e5c6ccd8efa4e822c70a0444fa6b5a31bebca
