am: f2796025ed
* commit 'f2796025edb2dbc53cef002fa92760352e55b6af':
Start VPN as early as possible during startup
Split network agent created state from connected state
Change-Id: Ibb02f2731536ebafaa4c24ef5cd2113f7cd43632
am: 31b3676cce
* commit '31b3676ccec847b1e86c23b2f5073dc1cc83abf4':
Start VPN as early as possible during startup
Split network agent created state from connected state
Change-Id: I6bb605a83b96a3efab36ab6a7bdb5859e1eafea8
am: c58c9ae0a9
* commit 'c58c9ae0a931b6c71d7924cfd4e900e8919a6fcc':
Start VPN as early as possible during startup
Split network agent created state from connected state
Change-Id: I55167ad8f3cde11407a2d35b0f859c263c0fbbec
- Switch from USER_STARTING to USER_STARTED which is the foreground
version of the broadcast
- Set the new VPN network as CONNECTING initially to avoid spamming
apps with useless notifications ahead of the network being fully
available
Bug: 26694104
Fix: 28335277
Change-Id: I31d5260dda62ff440c31c44eb0aa5c891e2717e5
Network creation setup sometimes involves extra steps after actually
calling into netd to create the underlying network, rules & routes &
to begin allowing sockets bound to it.
For example, VPN networks can set a UID whitelist or blacklist. This
should happen:
- AFTER there is a netID & network created in netd as
network-specific rules will need to be tied to / point at it. Those
rules are tied to the lifecycle of netd's network which is tracked
by `NetworkAgentInfo.created` on the frameworks side.
- BEFORE the CONNECTED broadcast and network callbacks have been sent
out so that we don't create a race condition between clients that
want to use the network and the server actually having the network
ready
The race condition existed prior to this change and required any client
making use of network callbacks to sleep for a short amount of time after
receiving to actually be able to use the network.
Among other things, that race condition is now fixed.
Bug: 26694104
Change-Id: Ied92f5588a98c3e97f456bc98b676bf201ab5472
Allows callers to opt-out of blockading network traffic during boot and
on VPN app failure.
Bug: 26694104
Change-Id: Ibfbd43ad09a25f2e38053fcd6306df3711f8bde2
am: 25bbae6e74
* commit '25bbae6e74ae01c72f2b68e110547afc6c4e96b6':
Flag to mark foreground jobs, fix data saver.
Change-Id: Id863d0ff4f8e7f13049231298feaab9839b4667c
am: 0c5c67f743
* commit '0c5c67f743abeba5c30112634ce82fd63ae2d1a1':
Flag to mark foreground jobs, fix data saver.
Change-Id: Idbf3bdfc76cadfbcb6bbf17ac1aa99df72a7a0a1
am: 4b6d6eb09f
* commit '4b6d6eb09fe922be19fac9fa1b289584e84d1bb0':
Flag to mark foreground jobs, fix data saver.
Change-Id: I30b87193a1d5d45f4ffeb919276a70ae709a1cdc
am: 9a977b7d45
* commit '9a977b7d45df0d3d59c5eec7f9534c3bd5fcd91d':
Flag to mark foreground jobs, fix data saver.
Change-Id: I908d725a84e9590d0da38a586b066a63473d4f28
When a job will eventually run in the foreground, the internal
scheduling needs to ignore any background network restrictions when
satisfying constraints. This also means the job should ignore the
current device doze state, since the requesting app could get the
same behavior by starting their own foreground service.
Always dispatch network policy changes to ConnectivityService first
to ensure that it has up-to-date information. Fix bugs around data
saver that were causing networks to not be marked as BLOCKED for
background apps; before this fix apps would have been spinning in
internal connectivity loops, thinking that the network was actually
connected when the kernel was actually blocking their traffic.
Offer new ConnectivityService method overloads to ignore the blocked
state for a specific UID.
Print unsatisfied job constraints to aid debugging.
Bug: 26571724
Change-Id: Iaaa17933e6dc1bf6d3dff26d0bfc12222e51e241
am: 49392af782
* commit '49392af78206b5fdd6dd120438503cb540aec70a':
Stop user faster and clear stale broadcasts
Change-Id: I5b69b7432f7cedd92f6891734643809e0170b3cc
am: 9dee0bccd8
* commit '9dee0bccd8e692d1ca86bcf7180170f153dc99c7':
Stop user faster and clear stale broadcasts
Change-Id: I16c4c1dfcff9f4d63da0444923a29fda0bea5ee8
am: 2bb6008a4c
* commit '2bb6008a4cd20654b268e13276c6a56ecc0eab2b':
Stop user faster and clear stale broadcasts
Change-Id: I423d1f8448f8ba5b54f90a2fa192f231f38b761c
am: ec6faca007
* commit 'ec6faca0078263dfbf2b41d11cdb14586e40fd75':
Stop user faster and clear stale broadcasts
Change-Id: I36eeb177791730a26077542606559e3e4428b87e
Moved several USER_STOPPING registered receivers to listen
to USER_STOPPED, since they don't need to be blocking the
shutdown of the user.
Clear all stale broadcasts when stopping a user, so that we
don't unnecessarily start up processes and deliver stale
broadcasts. This was causing code to run when the user was
already stopped and resulted in crashes when other providers
and services couldn't be started anymore. Hopefully this fixes
many of those races.
Bug: 28371487
Change-Id: Ic35a7a23fa8fe009a53f8bf7545d4dad5fa34134
am: 33ec772
* commit '33ec77265a8e9e401a5915884c4d9ec2b6e5407a':
Tethering and Data Saver: There Can Be Only One!
Change-Id: I184d03847abe86dd2f5e10c10bd12f90f7cc14d8
am: 7f026f8
* commit '7f026f8927c30180817f46ee38ee292ad05997ff':
Tethering and Data Saver: There Can Be Only One!
Change-Id: Idb0ab16443ca061f97ed2f12e0ee01d9fa61b187
am: 5af619f
* commit '5af619f1cdd78fa1cd799ea05f1b59b75b589a0d':
Tethering and Data Saver: There Can Be Only One!
Change-Id: I876c9a30e9451b1c346296c233068bdfb579f584
