When the ServerThread handles ACTION_SHUTDOWN intent it sometimes get
stuck on mStatsLock in NetworkStatsService.java.
0 com.android.server.net.NetworkStatsService$5.onReceive()
1 android.app.LoadedApk$ReceiverDispatcher$Args.run()
2 android.os.Handler.handleCallback()
3 android.os.Handler.dispatchMessage()
4 android.os.Looper.loop()
5 com.android.server.ServerThread.run()
This happens when the NetworkStats thread is already holding the
mStatsLock while updating NTP.
0 libcore.io.Posix.getaddrinfo()
1 libcore.io.ForwardingOs.getaddrinfo()
2 java.net.InetAddress.lookupHostByName()
3 java.net.InetAddress.getAllByNameImpl()
4 java.net.InetAddress.getByName()
5 android.net.SntpClient.requestTime()
6 android.util.NtpTrustedTime.forceRefresh()
7 com.android.server.net.NetworkStatsService.performPoll()
8 com.android.server.net.NetworkStatsService.access$100()
9 com.android.server.net.NetworkStatsService$2.onReceive()
10 android.app.LoadedApk$ReceiverDispatcher$Args.run()
11 android.os.Handler.handleCallback()
12 android.os.Handler.dispatchMessage()
13 android.os.Looper.loop()
14 android.os.HandlerThread.run()
Since the NTP update consists of several socket operations it may get
stuck long enough to trigger a System Server Watchdog even though the
socket timeout is set to 20 second.
Further, the NTP update doesn't actually need to be performed inside
the locks and an attempt to change this was made earlier, but the code
wasn't actually moved outside the locks.
Change-Id: Ib37a2b8c2d51a01adb7ff01764f82309433703f0
Throw early when structure is unstable, which allows the normal
recoverFromWtf() path to recover automatically.
Bug: 7440485
Change-Id: Ic150d17daac4de7c9ff3489025403a9b485b4620
Migrate networking, storage, battery, DropBox, and PackageManager
related Secure settings to Global table.
Bug: 7232014, 7231331, 7231198
Change-Id: I772c2a9586a2f708c9db95622477f235064b8f4d
When a user is removed, migrate all network stats belonging to that
user into special UID_REMOVED bucket. Also removes those stats from
kernel to avoid double-counting if another user is created.
Bug: 7194784
Change-Id: I03f1d660fe3754566326b7749cae8068fc224ea9
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
