This patches changes how captive portal tests and network lifecycle
events are logged as connectivity events:
- it splits NetworkMonitorEvent into two event classes:
- ValidationProbeEvent for logging individual probe events.
- NetworkEvent for logging network connection, validation,
lingering, and disconnection.
- it removes the redundant CaptivePortalCheckResultEvent class.
The information logged in CaptivePortalCheckResultEvent was already
logged by NetworkMonitorEvent, but missing the evaluation durations.
It is now logged by ValidationProbeEvent.
- it removes the CaptivePortalStateChangeEvent class, which is now
redundant with NetworkEvent, but missing evaluation durations.
In addition, it adds event logging when ConnectivityService puts a
network into lingering or removes a network from lingering.
Bug: 28204408
Change-Id: I8f9752e4d36175ecfcbd1545a01a41bad6e06ea4
Also fixed a few more issues with the header util that could
lead to wrong states.
Change-Id: I95c3479f5d9e5221ee9e91120271e7957b887607
Fixes: 28295743
Some apps out there do some creative things in terms of calling their
own onDetach methods from elsewhere. Perform the child FragmentManager
shutdown for retained fragments in a package-level perform method
instead of in onDetach itself.
Also mark all existing fragment methods with @CallSuper.
Bug 28293847
Change-Id: I343b610f8d427fe5cabd523a78fbf0e6f3b34c57
PendingIntent.FLAG_ONE_SHOT is needed to prevent the PendingIntent being
reused.
Also, flag and activity option of credential intent in BaseStatusBar
is not same as the one in ActivityStarter. Added a new
function startConfirmDeviceCredentialIntent in AM to centralize it.
Change-Id: I2d9e5923ad5d4d012f10057c409c666c8ca299a3
Fix: 28309964
- fold IpReachabilityMonitor* classes into a single IpReachabilityEvent.
- only log an event for NUD_FAILED Netlink answers.
- distinguish between NUD_FAILED with or without lost of provisioning.
- do not record host ip addresses.
- record interface name instead of interface index when losing
provisioning.
- also return an error code when probeNeighbor fails, and log this error
code in IpReachability events.
Bug: 28204408
Change-Id: I5f0def0ab1ace7e467a0c69b3b82d07ef2252307
There are two types of IMEs:
A. IMEs that have one or more subtypes
B. IMEs that have no subtype
The initial implementation to update hardware keyboard layout per
subtype change of layout (See Bug 25752812) has supported IMEs in the
category A only, and IMEs in the category B are just ignored in both
system and Settings app.
In order to support IMEs in the category B, InputMethodSubtypeHandle and
related methods need to accept null InputMethodSubtype. Technically
this is a straightforward change, because in InputMethodManagerService
we have already used InputMethodUtils.NOT_A_SUBTYPE_ID for those IMEs in
the category B. We also need to update Setting App, which will be done
by a different CL [1].
[1]: I46b9c5b018f08e3eaa4614a0893db0be91652f3c
Bug: 28182650
Change-Id: Ia013784a594ad3beaf30976d047f5ac0fa8185be
Print interval clamp message
only for periodic jobs having
period/flex less than the minimum value.
Bug: 28296128
Change-Id: Id0d7c3b56048582a490bb8214eca491ec2bbdc93
As a workaround for b/27870771, convert fatal exception into a
warning.
Duplicate calls to finishPendingSequence with the same sequenceId
are seen in user crash reports, but with no further context and
inability to reproduce after testing various hypothesis, just
warn about it happening.
Bug: 27870771
Change-Id: Icd7d408887e04b94092689ce61809d6c664d8e3a
In addition, now that the full uncropped wallpaper image is being
backed up, we now handle that via the full-data backup path instead
of key/value. Restore still knows about legacy data that gets
delivered via the older key/value mechanism.
This change also has the effect of removing the size limitations
around wallpaper restore acceptance. Any size source imagery is
valid, as crop & scale are rerun in a device-appropriate way
after the restore.
Bug 25453848
Bug 25727875
Change-Id: Idc64a2eaab97a8ecc9d2b8ca5dc011f29cab324d
When choosing what window parameters to pass on
to child windows, we need to respect the manually set
FLAG_HARDWARE_ACCELERATED from Window.setFlags() in
addition to the activity manifest value, and the value
from setWindowManager. Given that we pass the value
on to child windows from when setWindowManager is called,
I think it makes sense to pass it when setFlags is
called.
Bug: 27099358
Bug: 23036374
Change-Id: Ie018841aadd270910fe0f8bc5a5ddca3bfbee69b
