This patch is a partial cherry-pick from commit
df456e13a1 for the BitUtils and
NetworkCapabilities classes.
Bug: 34901696
Test: none
(cherry picked from commit df456e13a1)
Merged-In: Id04f9080e7f75608deeb49306aec34941e71794c
Change-Id: I64eae49f646365b7cd1683a689315fe03bf0bdd9
If anything unrestricted is bundled in the whole thing has to be
unrestricted (we can't restrict based on destination or intent)
but the NOT_METERED flag wasn't taken into account.
This wasn't a problem before because telephony set that statically
and late, but a change caused it to be marked NOT_METERED earlier
which exposed this bug.
bug: 37208956
Merged-In: I7b7a1c38621ce0ecde8cf041e82b1ebb7a9c6f15
Test: new NetworkCapabilitiesTest. Fails without fix, works with.
Change-Id: I86c1b2854413a94662aa53e697d32380695ab9ac
Wifi Aware networks are per app - i.e. a requestor gets
a dedicated network. Change verifies that the only the
original requestor matches the created network (using UID).
Bug: 36053921
Test: Integration (sl4a) tests
Change-Id: I4ff3994731dd7ccb88e2bea333d1e6905b136f02
This prepares some refactoring and the addition of a timeout to
resolveService.
Test: new tests pass
Bug: 37013369, 33298084
Change-Id: Ie8277bd5983278507bfa70495b4ce7d13895b24b
There are intermittent issues where either the returned Bluetooth
MAC address to Java framework is uninitialized or this address update
arrives too late. This fix will do 2 things:
(1) Returns error when MAC address is unavailable in the native code.
(2) Updates the MAC address later by adding a new broadcast event.
Test: Check address for these cases: factory reset, system reboot, and
Bluetooth re-enable.
Bug: 36709382
Change-Id: I09720193e38fdf9139e1bb146f8e1847e2b65b1a
And also remove some small code duplication (checkNotNull).
Test: built, flashed, runtest frameworks-net
Change-Id: Id6c13bca9d12f70b88806032e0a4fa198efbedc6
This patchset adds a hidden method getOwnAddress, that lets app with
BLUETOOTH_PRIVILEGED permission to lear their own addreess. This is done
exclusively for PTS tests.
Bug: 35147497
Test: manual
Change-Id: Iaf0f2fe0613de44b8430ac25e691d66a4ad44f8d
Symptom:
AppOps verified the incorrect package of calling tether state
changing API.
It threw SecurityException by mistake.
Solution:
Pass the correct package name to enforceTetherChangePermission.
Bug: 32931147
Change-Id: Ia1167f26f556678b189a24a4a716f1a7e5cb12eb
Add a hidden api for reading characteristic by UUID for PTS.
Bug: 35150313
Test: sl4a GattReadTest.byUuid
Change-Id: Ice4076d99e4694d20374ba0fdcae74d5ae841147
These methods do not currently work for IPv4 sockets,
so they need to be hidden until the underlying kernel
code can be made to work properly in a dual-stack
environment.
Bug: 36073210
Test: compilation
Change-Id: Idce367f638a42da374a7f1dc5ebb8931c9555e06
This patch changes how callback unregistration works in order to be
consistent with undocumented use cases currently de-facto supported
by the API (although in a buggy way):
- callback recycling: releasing then reregistering a callback again.
- multiple request registrations with the same callback.
The second use case is not desirable but needs to be taken into account
for now for the purpose of correctly releasing NetworkRequests
registered in ConnectivityService.
In order to support request release in both use cases with minimal
amount of complexity for the time being the following changes are done:
- request to callback unmapping is done synchronously at callback
release time.
- all requests associated to a callback are unmapped at callback
release time.
This fixes the following issues:
- a callback stops being triggered as soon as it is released.
Otherwise when recycling the callback immediately, it is possible
the previous request associated with it triggers it, confusing the
app.
- when a callback is registered multiple times, the requests are not
leaked.
- when a callback is registered multiple times and then released, the
N-1 first registrations do not trigger the callback anymore.
In the future it would be desirable to enforce the intended 1:1 mapping
between callbacks and requests at registration time.
Bug: 35921499, 35955593, 20701525
Test: - added new tests in ConnectivityManagerTest to test releasing,
recycling, and a disabled test for no multiple regristration.
- new tests catch regression causing b/35921499, b/35955593.
Change-Id: Ia0917ac322fc049f76adb4743bc745989fed6d26
android.os.VintfObject has two methods:
- report: return device info that can be reported to OTA server
- verify: verify that metadata for a given OTA package is
compatible.
Test: pass
Test: adb shell am instrument -w -e class android.os.VintfObjectTest \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Bug: 36814503
Change-Id: Iff8fae289eec8ae9cfc327d0d0d36a1cdd5e6800
This patch introduces a new settings value to specify more than one url
for the fallback http probe in addition to the existing settings value.
If more than one url exists, a network will rotate urls for the fallback
probe one by one everytime the fallback probe is sent.
(not like commit 0908daaaf0, this patch
uses a comma to separate fallback urls, which works as expected with
Java's String.split())
Test: built, flashed, tested manually with various portal networks.
Bug: 36532213
Change-Id: I3c010bfee5b99db03a500776fbf47959a29d0578
