At present the network evaluation / captive portal detection
is disabled pending addition of API to bind socket to network.
Change-Id: I5d1f5dc86d4dd9481d52dd45d6da0732054c8315
NetworkFactory and NetworkAgent. First trying with wifi and
getting rid of WifiStateTracker.
Conflicts:
api/current.txt
services/core/java/com/android/server/ConnectivityService.java
Change-Id: I7f0ec13d7d8988b32f3c6dc71f72012f3349fe02
This is a protocol allowing transports to dynamically register with CS for
Handler to Handler communications.
bug:13885501
Change-Id: Ic7275e3724a15efc7e5f80981560c4cb3106007b
The multinetwork branch is rebooting on startup with:
E/AndroidRuntime( 1024): *** FATAL EXCEPTION IN SYSTEM PROCESS: NetworkStats
[...]
E/AndroidRuntime( 1024): Caused by: java.lang.NullPointerException: Attempt to read from field 'long android.net.NetworkCapabilities.mNetworkCapabilities' on a null object reference
E/AndroidRuntime( 1024): at android.net.NetworkCapabilities.<init>(NetworkCapabilities.java:235)
E/AndroidRuntime( 1024): at android.net.BaseNetworkStateTracker.getNetworkCapabilities(BaseNetworkStateTracker.java:103)
E/AndroidRuntime( 1024): at com.android.server.ConnectivityService.getAllNetworkState(ConnectivityService.java:1134)
E/AndroidRuntime( 1024): at com.android.server.net.NetworkStatsService.updateIfacesLocked(NetworkStatsService.java:877)
E/AndroidRuntime( 1024): at com.android.server.net.NetworkStatsService.updateIfaces(NetworkStatsService.java:849)
E/AndroidRuntime( 1024): at com.android.server.net.NetworkStatsService.access$600(NetworkStatsService.java:139)
E/AndroidRuntime( 1024): at com.android.server.net.NetworkStatsService$2.onReceive(NetworkStatsService.java:717)
E/AndroidRuntime( 1024): at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:766)
E/AndroidRuntime( 1024): ... 4 more
This seems to be due to NetworkCapabilities' copy constructor
not null-checking its argument. Unbreak things by ignoring null.
Change-Id: Iff3c38e6d72390fa86e51bfce534ebd42a262e19
Since the interface for creating/accessing PAC URLs through a
ProxyInfo is Uri based, so should the internal storage and
references.
Change-Id: Ibf15c350f4cc526f81aba3ec463070f26af8f535
A network subsystem (e.g. Wi-Fi) will be responsible for implementing
INetworkScoreCache. NetworkScoreService will load caches for each
configured network subsystem. When it receives a call to update
scores, it will separate the networks by type and call updateScores on
the appropriate INetworkScoreCache.
Each subsystem will also be responsible for requesting scores for new
networks by calling NetworkScoreManager#requestScores.
Bug: 14408144
Bug: 14137255
Change-Id: I76e5e5205bc359c39d6b9c1782126fb7f465cd96
adb shell dumpsys activity broadcasts
has the last 100 broadcasts, so it can be used for debugging
instead of spamming the main logs.
Change-Id: I19c3ac72eb783999e615261da7f00b527d2bc06f
Expose "isAppValidScorer" so Settings can call it.
Also rename ACTION_CHANGE_DEFAULT to ACTION_CHANGE_ACTIVE for
consistency with other naming.
Change-Id: I6c2d0099622958f06c2916ca76090e14d5273c86
Define new FLAG_GRANT_PREFIX_URI_PERMISSION which indicates that a
Uri permission grant should also apply to any other Uris that have
matching scheme, authority, and path segments. For example, a prefix
grant for /foo/ would allow /foo/bar/ but not /foo2/.
Allow persistable and prefix grants to be issued directly through
grantUriPermission(). Relaxing persistable is fine, since it still
requires the receiver to actively take the permission.
Since exact- and prefix-match grants for the same Uri can coexist,
we track them separately using a new UriGrant key. (Consider the
case where an app separately extends READ|PREFIX and WRITE for
the same Uri: we can't let that become READ|WRITE|PREFIX.)
Fix revoke to always take away persisted permissions. Move prefix
matching logic to Uri and add tests. Add new flags to "am" tool, and
various internal uses around Intent and Context. Switch some lagging
users to ArraySet.
Bug: 10607375
Change-Id: Ia8ce2b88421ff9f2fe5a979a27a026fc445d46f1
This service will ultimately be responsible for propagating scores
down to lower-level network subsystems. For now, it just keeps scores
in memory and exposes these for debugging purposes via "adb shell
dumpsys network_score".
This change also adds provisioning of a default scorer. When
NetworkScoreService is first initialized, it checks to see if it has
ever set a default scorer; if not, it reads a package name from a
build config property and attempts to set it as the default.
Also add autogenerated equals/hashCode methods to all parcelables.
Bug: 14111427
Bug: 13786258
Change-Id: I02271171653d42e12acd240b73b9e23950744f6b
Allows listing all possible scorer apps, getting the active scorer
app, setting the active scorer app, and determining whether a given
UID is for the active scorer.
Note that setting a default scorer with a system image will be handled
separately - the plan here is to add a read-only build property
containing a package name to use as the scorer out of the box.
When NetworkScorerService is initialized, it will check a provisioning
bit; if that bit isn't set, it will set the current scorer to the
package specified in this build property (if any) and set the
provisioning bit to true.
Bug: 13769362
Change-Id: I18c0b2ba2aceccc88b70c3611a49149e0bf17ecf
NetworkScoreManager defines all interactions between the framework and
the scorer app. An ACTION_SCORE_NETWORKS broadcast is sent to the
default scorer with any unscored networks, which responds by calling
updateScores() with scores for those networks. An app may also check
whether they are currently the default scorer with
getDefaultScorerPackage() and request to become the default via the
ACTION_CHANGE_DEFAULT broadcast.
Bug: 13786258
Change-Id: Id3dc0f7c1109f0e3afd73356e2475b7f34167419
NetworkKey represents the necessary information to identify a network
to be scored. ScoredNetwork contains the key to identify a network as
well as a score to be used when evaluating that network (as a curve
based on RSSI).
Bug: 13767776
Change-Id: I6bfebd105c9381e615513167b4332b767b43a23a
The API and implementation of NsdManager imply that a separate
Listener is to be used for each active registration or discovery
request. This isn't formally documented or properly enforced, and
weird and unpredictable things happen if an application uses a
Listener for more than one request at a time.
Update documentation to make this an explicit requirement.
Enforce the restriction when a new request is submitted for
processing; if the Listener is already being used to track an active
request, throw an exception.
Document the fact that apps should unregister services and cancel
service discoveries when the app is stopped (in KitKat and prior
releases, they'll leak if this isn't done.)
Re-order "release the Listener" operation to occur before the Listener
callback, so that the Listener can be reused by the application once
the callback has been entered - this eliminates a race condition.
Document this.
Pass 2: typos, added documentation about API level, changed to using
an explicitly defined return value for "busy listener".
Bug: 13512512
Change-Id: Ic164110759204b27d8a14376777b593ebe1865fa
