| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Not needed since java.util.Objects implements all the needed
functionality.
Change-Id: Icd31d49a9801d1705427f028e9ac927d58e7d34c
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently BaseNetworkObserver is in frameworks/base/services, but
there is code in frameworks/base/core that could use it. This
code typically extends INetworkManagementEventObserver.stub
because BaseNetworkObserver is not available.
Move BaseNetworkObserver to frameworks/base/core without changing
its package name, and use it to simplify two callers. The third
caller, Tethering, is much larger, and I'm not sure it's
appropriate to change it.
Bug: 10232006
Change-Id: Ifc0f2e619e3424e27e35730c048a1cc523df345e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
VPNs are now per user instead of global. A VPN set by user A routes only
user A's traffic and no other user can access it.
Change-Id: Ia66463637b6bd088b05768076a1db897fe95c46c
|
|
|
|
|
| |
Bug: 9564691
Change-Id: I5b5f78c9ae20505f6274b91bc8fdbaaf57443277
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent changes started watching for CONNECTIVITY_ACTION broadcasts
to handle the case where a network is disconnected without the
interface going down.
However, when lockdown VPN is enabled, the broadcast contents are
augmented, and all connections appear disconnected until the VPN
comes online. This caused a reset feedback loop to occur.
Since LockdownVpnTracker already handles networks being disconnected
separately from interfaces going down, this change disables handling
the broadcast when lockdown is enabled.
Bug: 8755148
Change-Id: I70a348aa97a4b22eaaf23aa5ed344de3e9a9ab0b
|
|
|
|
| |
Change-Id: I15e8f0e4a6c5546d9be956ca0d46715d3441458c
|
|
|
|
|
| |
Bug: 8067988
Change-Id: I6cb7d07e0c4b7c6e112a26a06892e859e6b515a8
|
|
|
|
|
| |
Bug: 7064111
Change-Id: I9554f6a426697b4abeb2ddd0827d314920e88ed6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).
Add operation for retrieving neighboring cell information.
Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.
Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
|
|
|
|
|
|
|
|
| |
WifiInfo changed to return SSIDs with quotes included, so relax our
identity matching to accept matches regardless of quotedness.
Bug: 7695807
Change-Id: Ib5d06666035e06b2d4b2f7cb498767d63b1b1828
|
|\
| |
| |
| |
| | |
* commit 'bf8de6a349e19b32a1577080a9d8bb7f92b2301f':
Remove unnecessary locking for screen broadcasts.
|
| |
| |
| |
| |
| |
| |
| | |
The actual handling occurs in updateScreenOn() on the other side of a
handler, which acquires the lock correctly.
Change-Id: Ibd359446dba8e88f81d34f1e10a6b5e150348f89
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
jb-mr1.1-dev
* commit '1f8f283975c7cf51081acd3ea494de2b5f431607':
Avoid null mobile interfaces.
|
| | |
| | |
| | |
| | |
| | | |
Bug: 7634215
Change-Id: I6745f6a78c07ba11d98b4562a6b53386112ef652
|
|\ \ \
| |/ /
|/| /
| |/
| | |
* commit 'ae0edeb3e56c6aae113f8c5eaa3a03b79c00a93e':
Move NTP updates outside locks
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
| |
Bug: 6537978
Change-Id: I806c3c09e3255f8789455f13bf37c1dde2a93f1f
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Bug: 7148397
Change-Id: I20e2194c874544b272b9ec8b63391d91b0a22f49
|
|
|
|
|
|
|
|
|
| |
For multi-user devices, switch to storing policy per-user instead of
per-app. Also watch for user added/removed broadcasts to clean up
policies and apply global restrictions.
Bug: 7121279
Change-Id: Ia7326bd0ebe0586fa4ec6d3a62f6313dc8814007
|
|
|
|
|
|
|
| |
Also add better ConnectivityService logging.
Bug: 7157464
Change-Id: Ia235a7e62ed809240913c4782920c1410c7d597d
|
|
|
|
|
| |
Bug: 7157464
Change-Id: Ief10fd37940f62420f5684940994c9f93802e0be
|
|
|
|
|
| |
Bug: 7079350
Change-Id: I3670efe7f09c0fca55552b6a04a2be159b9beb3c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replaced all remaining places that used it with explicit user
specification.
While doing this, I ran into stuff that was creating PendingIntent
objects (that now need to specify the explicit user they are for),
which are also posting notifications... but have no way to specify
the user for the notification.
So the notification manager in the system process now also gets a
formal concept of a user associated with the notification, which
is passed in to all the necessary aidl calls. I also removed the
old deprecated aidl interface for posting/cancelling notifications,
since we now always need a user supplied.
There is more work that needs to be done here, though. For example
I think we need to be able to specify USER_ALL for a notification that
should be shown to all users (such as low storage or low battery).
Along with that, the PendingIntent creation needs to be tweaked to
be able to handle USER_CURRENT by evaluating the user at the point the
pending intent is sent.
That's for another change, however.
Change-Id: I468e14dce8def0e13e0870571e7c31ed32b6310c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Otherwise lockdown VPN reset is racy and can bring down system_server.
Change-Id: Ib8eecde1d0857a1669c3ca5506a46198c71b1b51
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds support for always-on VPN profiles, also called "lockdown." When
enabled, LockdownVpnTracker manages the netd firewall to prevent
unencrypted traffic from leaving the device. It creates narrow rules
to only allow traffic to the selected VPN server. When an egress
network becomes available, LockdownVpnTracker will try bringing up
the VPN connection, and will reconnect if disconnected.
ConnectivityService augments any NetworkInfo based on the lockdown
VPN status to help apps wait until the VPN is connected.
This feature requires that VPN profiles use an IP address for both
VPN server and DNS. It also blocks non-default APN access when
enabled. Waits for USER_PRESENT after boot to check KeyStore status.
Bug: 5756357
Change-Id: If615f206b1634000d78a8350a17e88bfcac8e0d0
|
|
|
|
|
|
| |
This is the start of turning this into a formal public API.
Change-Id: I5786d2c320f1de41a06ed5d0f65adb68967287a0
|
|
|
|
|
|
|
|
|
|
| |
Moved a bunch of methods from PackageManager to UserManager.
Fix launching of activities from recents to correct user.
Guest creation APIs
Change-Id: I0733405e6eb2829675665e225c759d6baa2b708f
|
|
|
|
|
|
|
| |
This makes it easier to add new INetworkManagementEventObserver events
in future.
Change-Id: I432263d745558de4b878f313c1951230ed9db2b1
|
|
|
|
| |
Change-Id: Ib34e294747405b7ab709cb0bbb2d9a0cc80ce86a
|
|
|
|
|
|
|
|
| |
The activity notification is received from netd, an intent
DATA_ACTIVITY_CHANGE is then raised for other part of the system to
consume.
Change-Id: Idfcc4763c51c5b314c57f546c12557082f06bebf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NetworkPolicy currently uses a single background thread to process
various broadcasts. When processing other broadcasts, this thread
can block our handling of SCREEN_ON/OFF, which are sent as ordered
broadcasts.
This change moves SCREEN_ON/OFF handling to the main thread, and
dispatches a one-way message to the background thread, allowing the
ordered broadcast to always proceed.
Bug: 6677047
Change-Id: I52de2c7b75beb8059bb87e123689ba4a9c4ae349
|
|
|
|
|
|
|
|
| |
Continues to check MANAGE_NETWORK_POLICY permission. This allows
SystemUI to invoke snoozeLimit() without CONNECTIVITY_INTERNAL.
Bug: 6653091
Change-Id: I464bf62b79f2647c6b6db151251a0036897d0cc0
|
|
|
|
|
|
|
|
| |
It now has a new callback to report changes in the "importance"
of processes. Rewrote the dispatching code to be a bit more
efficient now that we are sending more reports.
Change-Id: Ie865cfd286455819f04e8c14e9b6fd54d028f8f2
|
|
|
|
|
| |
Bug: 6492166
Change-Id: Ibebdc7e9b8cae27c12fd7b61b53ab60287a0364d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When XT stats are available, transition to prefer them over DEV,
since they aren't subject to hardware driver bugs. Only switches at
the first atomic XT bucket, and adds a Settings.Secure flag to force
back to DEV if needed. Includes tests to cover transition.
Fix tests where device overlay would change which network types
reflected data usage. Test both history and summary APIs. Fixed
collection timestamps to reflect full buckets.
Bug: 6504744
Change-Id: Idd7f3b2fdb064c36547c85c51c214fd938c59b7e
|
|
|
|
|
| |
Bug: 6472388
Change-Id: I70e1ed5dc75056840f2f0b130ce0dfecb06f385e
|
|
|
|
|
|
|
|
|
| |
In rewriteSingle(), catch Throwable to rollback to backup file,
instead of just IOException. Also add dumpAll() to pack up contents
for later debugging, and use it when encountering bad stats.
Bug: 6467868
Change-Id: Ic8e287cf5a235706811a304a88d71d11d3a79cd4
|
|\ |
|
| |
| |
| |
| |
| | |
Bug: 6449725
Change-Id: I702dc2ff9d4b237c46d89bcae41289bc3e9ef2f8
|
|/
|
|
|
| |
Bug: 6447017
Change-Id: I705a223dac15fc41e231bb9c81a96a287caaf094
|
|
|
|
|
|
|
|
|
|
| |
Default is 2MB persist threshold, but even that can be substantial
for devices on 100MB/month plans. This change gradually reduces the
persist threshold up to 8x lower (256kb outstanding) based on lowest
active policy.
Bug: 5382676
Change-Id: Ief4e8cdb169bfb151a3d1b45722a8eaa01926508
|