- add a new field: provisioningNotificationEnabled from NetworkMisc. set
to false if we want to hide "sign in" notification and placed
carrier-specific notification instead. it is set on connect, once set,
it is carrier-app's responsibility to post new UI to users
- rework on the interaction between carrier app and framework
- code cleanup
- unit test support
Bug: 28567303
Change-Id: Ic84db7ffbb920d15344717f104496d3cb82e1a85
am: 2690d59a11
* commit '2690d59a1113acfa48fe701df1d6f991ead14452':
API council feedback: hide and document.
Change-Id: I002236f584ddc7a5f479b8936e4b5f5ed61759eb
am: 19e2f49181
* commit '19e2f49181b209d790f551b374d6d24002de7c9b':
API council feedback: hide and document.
Change-Id: I3715fc6e824f2a55517788299afe36145db597d7
am: 1cd027befe
* commit '1cd027befe8206fe4c33b1efff2bebb0584c138c':
Make some of the UID-based VPN code reusable
Change-Id: I75d9871f8039d14f8d83be4696c3c4d4e864f9c0
am: b0f3016b64
* commit 'b0f3016b64552674681dbc742667203d36c4c86d':
Make some of the UID-based VPN code reusable
Change-Id: I3f1b1a08059aa58cb76db6cdd070b103024b9bf3
am: 13d5a1d648
* commit '13d5a1d648bd71e92347dd30629648c90326fccf':
Make android_net_NetUtils include what it actually uses.
Change-Id: I775c03ba7fd3895c6525d3986b564b228d34063b
By changing some member refs into arguments and having one of the
functions create the UID range instead of adding to mVpnUsers.
This will be useful for other layers of UID filtering like having
UIDs explicitly blocked from the VPN.
Deleted one broken line of code that cleared the status intent when
a restricted profile is removed. Other than that, this commit shouldn't
change any behaviour. If it does, that's a bug.
Bug: 26694104
Change-Id: Ieb656835d3282a8ba63cc3f12a80bfae166bcf44
Allows callers to opt-out of blockading network traffic during boot and
on VPN app failure.
Bug: 26694104
Change-Id: Ibfbd43ad09a25f2e38053fcd6306df3711f8bde2
am: a410ef9790
* commit 'a410ef97906acf76554948cb44981af4563c1198':
Flag to mark foreground jobs, fix data saver.
Change-Id: Id863d0ff4f8e7f13049231298feaab9839b4667c
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
Place helper map for callback field names into a holder. This avoids
the reflective calls in static initialization of ConnectivityManager
in the common (non-debug) case, which means the class can be
compile-time initialized. Also saves the storage necessary (both
the storage array as well as the reflection metadata).
Follow-up to 7e28683228.
Bug: 27265238
Change-Id: Ib4bfaf27acd234a035a5d198458340099a156a4c
To support moving DownloadManager, add new JobScheduler network type
constraint that matches "any network except roaming." Also add an
API to get a specific JobInfo by ID.
Since the default network can be different on a per-app basis, and
individual apps may be blocked due to app standby, evaluate job
connectivity constraints on a per-UID basis. To implement this
cleanly, add NetworkInfo.isMetered() to match the isRoaming() API.
Add new DownloadManager APIs to support charging and device idle
constraints, which are plumbed through to JobScheduler under the
hood when scheduled.
Add filtering to JobScheduler dumpsys to omit noisy details for
packages the caller isn't interested in.
Bug: 28098882, 26571724, 19821935
Change-Id: I09ca7184ef7ce6adba399f579d415a5fb2ea6110
The JavaDoc for many of the requestNetwork and
[un]registerNetworkCallback APIs incorrectly mentions the
PendingIntent version of the APIs instead of the NetworkCallback
version.
Also fix a minor issue in the registerDefaultNetworkCallback
JavaDoc: the default network request is an implementation detail,
so don't mention it. Instead, talk about the "system default
network".
Change-Id: Id94d98261daa2bd768c10e033cb8092729b21c91
am: 2c1f03a
* commit '2c1f03ade023a61428b7d9101bc10e4c88ae941a':
If Internet probe is redirected, pass redirect destination to NetworkAgent.
Change-Id: I4c5f5cb8591d8729de9036a6c2aabacd4aba0f39
Transport may use the redirect to make additional determination about network
state.
Bug: 25203607
Change-Id: I07d8918f13fdcbe0b6fd757536bfc1850a2a244f
am: a948f88
* commit 'a948f8872aa045ab22f42285f195fdb413c5ff66':
Internal API for system apps to determine default network for other apps
Change-Id: Ib719f0cebb41afe4aa52241f3797598a7e468d2d
Callers with CONNECTIVITY_INTERNAL permission can read off the netId
that an application is assigned to by default.
Necessary for making connections as the default network for a client
app eg. when downloading stuff on its behalf.
Bug: 27074270
Change-Id: I8d35e8e99126875f55f3c545090326f3e9be43fb
am: a577a3a
* commit 'a577a3a29f601fd2b71ad89eedcc52bdd8efbccb':
Make public the registerDefaultNetworkCallback API
Change-Id: Ic749ede5b84e443fed04701ecdd0f6521a77158f
There's a few advantages to having ApfFilter in IpManager:
1. If things go wrong, crashing a particular transport is less bad then
crashing ConnectivityService. We also don't want to use
ConnectivityService as a dumping ground for transport-specific logic.
2. This makes implementing WifiManager.MulticastLock a lot simpler and
safer because enabling/disabling it doesn't have to go through the
NetworkAgent, which could risk various races (e.g. installing a filter
into the wrong WiFi network).
3. IpManager is the ultimate source for LinkProperties for a particular
transport and since ApfFilter uses the LinkProperties it's better to
have it closely paired with the IpManager. Likewise, ApfFilter needs
to know the APF capabilities of the transport, so having it in
the transport avoids having to parcel this information through the
NetworkAgent.
Bug: 26238573
Change-Id: I99b85f2b64972f0e7572170ec5d1926081aa3429
