Add a new constructor to accept a DelayeDiskWrite object from the
caller.
BUG: 27293150
Change-Id: I13fb86c76ee5a0d05b45fec0c42b7e1b2233ee76
TEST: `runtest frameworks-wifi`
This centralizes code that is shared by both bluetooth and ethernet
transport layers.
Bug: 26991160
Change-Id: I8e2dd8580c29c86394119768e3a5529850b4b859
This class uses reflection to find accessible static integer
members in a specified list of classes and returns a SparseArray
mapping the integers to their names. This will allow us to
replace various 400-line switch statements with a simple
array access.
Change-Id: I3607e6389a423cde0bd83270c00b3c863ae1bb29
Additionally, remove IpManager.Callback#usingIpReachabilityMonitor()
now that this is now longer used.
Bug: 26991160
Change-Id: I9a17497c82238a9fb37a20d01aeca7bc4913ae2c
This class captures provisioning request parameters to be passed to
IpManager#startProvisioning().
Bug: 26991160
Change-Id: I56652bbc4b9ae6cfca3f225a8d99cdfc01bb54d9
With this it's possible for callers to:
Network network = ...
LinkProperties lp = ...
NetworkDiagnostics netdiag = new NetworkDiagnostics(network, lp, 5000);
netdiag.startMeasurements();
netdiag.waitForMeasurements();
boolean result = true;
for (Measurement m : netdiag.getMeasurements()) {
if (!m.checkSucceeded()) {
result = false;
// Additional error handling here.
}
}
return result;
Bug: 21832299
Bug: 26780890
Change-Id: Iaf7ff029e2c6a998b574c23d0dcde8d57a467a22
libc++.so is no longer accessible to the app, so it must be
bundled in the app. This should get ApfTest passing again.
Change-Id: Ide004cb84f7f50feffb8f5acb46b7001dcffd208
libnativehelper.so is no longer accessible to the app, so it must be
bundled in the app. This should get ApfTest passing again.
Change-Id: Ie4fe66e44d46ddb12b3c7ac5c91118a69a8ebe2e
1. Unhide MSIM APIs in TelephonyManager that already have non-MSIM equivalent
APIs public.
2. Make MSIM API naming consistent (overloaded, no suffix).
3. Unhide APIs in SubscriptionManager that are necessary for MSIM.
Bug: 26772894
Change-Id: Ibebab7379ea79c8e4812bbd190342827048e30e2
Current usage of NetworkSpecifier: network factory will match a request
if the request has either a (1) empty network specifier, or (2) a
network specifier which is identical to that of the network factory.
Note: 'matching' w.r.t. network specifier - all other matching rules
are still in effect.
Change: add rule (3) or the network specifier of the network factory
is the special string (which is defined as "*" and which user-facing
network requests aren't allowed to use).
Rationale: allows on-demand network creation.
Example:
- Can specify a Wi-Fi NetworkRequest with NetworkSpecifier="ssid"
- It will match a Wi-Fi network factory specifying NetworkSpecifier="*"
- That network factory will bring up a Wi-Fi network, connecting to the
specified SSID.
- Once the network is created it will create a NetworkAgent which will
now have a NetworkSpecifier matching that of the request (not the
match-all special string!)
That final step of making sure that the NetworkAgent matches the request
and not the match-all is critical to delivering any subsequent callbacks
correctly. I.e. your network will only get callbacks which match it.
Bug: 26192833
Change-Id: I49e3b492e0bb48a3f6e9a34e3f94f0e1cf89741f
If a direct listener alarm attempts to match a regular
PendingIntent alarm, it will attempt to fetch the binder of the
regular alarm's direct listener, which is null, and crash the
system with an NPE.
Cherry-picked from 9b43ce0c98ce9f865d6db547529d098c8982cc
Bug: 25823676
Change-Id: I85fb98b43436930a2513274dc5ab408f7d41d97f
The Alarm Manager now supports a set() variant that takes a listener
callback to invoke at alarm trigger time rather than a PendingIntent.
This is much lower overhead and has guaranteed low delivery latency
from the trigger time. The tradeoff is that the app must be running
*continuously* from the time the alarm is set to the time it is
delivered. If the app exits for any reason before the alarm fires,
the listener becomes invalid and the alarm will be dropped. This is
more or less equivalent to setting an alarm with a broadcast
PendingIntent that matches only a runtime-registered receiver.
The app's alarm listener can be any object that implements the new
AlarmManager.OnAlarmListener interface and implements its onAlarm()
method. There is no data delivered at alarm trigger time: whatever
state needs to be associated with the specific alarm instance should
simply be packaged inside the OnAlarmListener instance.
An alarm using OnAlarmListener can request that the onAlarm() method
be called on an arbitrary handler. If the program passes 'null' for
this parameter when setting the alarm, the callback occurs on the
application's main Looper thread.
Cherry-picked from 14a7bb0d370fffdf902a4e2345f46754ed2d7684
Bug 20157436
Change-Id: I2eb030a24efdd466a2eee1666c5231201b43684b
- netlink from core to services/net/netlink
- IpReachabilityMonitor from core to services/net/ip
Cherry-picked from 02cc5a030a6f132e776b754dd5684ae632009f76
Change-Id: I45ac3f591bade45dd5ec441111b02b621234c0e4
The flag is being obsolete by the move to JIT.
(cherry picked from commit 9abbf45c8dcdb2e5b13b615e5138ad996fe8afa3)
Change-Id: I3ce4577e81f91e9dd55d44116e0f9e2014bd00b8
If an L device has a privileged app on the system image which was
updated and an M OTA renames the app package (supported only for
privileged apps) we end up with a disabled system package setting
with no package information. Since we are not doing a null check
of the package we get from the disabled package settings during
default grants we crash leaving the system in a bad state.
bug:25687380
Change-Id: I4f2ebcaf471e4bd1696298eab4716b50c52ca5c4
Android currently forces USB into MTP mode if there was no modes
specified. This causes issues on Clockwork devices as they do not
support MTP.
The hack stops this behaviour, and also sets MTP mode back to none.
Bug: 25547826
Bug: 25582050
Bug: 25244201
Change-Id: I772e35d0a5db51b17e9d71c59e6a157dabb1d296
It is possible for an external process (e.g. sys-ui) to call into
WM to get the bounds of a stack in between the construction of the
DisplayContent object and SystemServer telling WM that the display
is ready. Incorrect bounds would be returned to the caller in this
case since the baseDisplayWidth/Height is only set when the displayReady
call is made.
We now initialize the base display information when the DisplayContent
object is created so any call to get the logical display rect of the
display will always return the right bounds. This should be okay as the
display manager is initialized way before window manager.
Bug: 22961090
Change-Id: Iebd688ad8f4c08556846fcebb543e58bd2c01414
