...startActivityForResult causes SecurityExpcetion
The ReferrerIntent hack was becoming visible to apps, which caused
a mismatch between marshalling/unmarshalling of the IPC call.
Change-Id: Ibcb788327b5bae4426efc826551799fa87d1cbaa
The basic principle is: if an app's traffic could possibly go
over a network without the app using the multinetwork APIs (hence
"by default"), then the status bar should show that network's
connectivity.
In the normal case, app traffic only goes over the system's default
network connection, so that's the only network returned.
With a VPN in force, some app traffic may go into the VPN, and thus over
whatever underlying networks the VPN specifies, while other app traffic
may go over the system default network (e.g.: a split-tunnel VPN, or an
app disallowed by the VPN), so the set of networks returned includes the
VPN's underlying networks and the system default.
Specifically:
1. Add a NETWORK_CAPABILITY_VALIDATED bit to NetworkCapabilities.
2. Add a hidden API to retrieve the NetworkCapabilities of
all default networks for a given macro-user.
3. Modify the status bar code that used getActiveNetworkInfo to
determine which network was active, and make it consider all
validated networks instead.
4. Because the set of active networks depends on which VPN app
the user is running, make the status bar re-evaluate the
networking situation when the active user changes.
Bug: 17460017
Change-Id: Ie4965f35fb5936b088e6060ee06e362c22297ab2
Don't clear notification LEDs when seeing notifications on the
lockscreen.
Also fix a bug where the LED didn't continue flashing after
the screen turned off.
For devices with doze capability, ensure that the LED continuing
to flash after screen off doesn't cause an immediate pulses, but
delay the first pulse by 10s.
Bug: 15449039
Change-Id: Id34d51a2c91ceaf069e49add1ab690bb855f9638
Pull the "Work" profile item up out of the main list and into the
header of the resolver drawer, making it easier to discover and access
without disrupting the sort order of the list.
Bug 17935301
Change-Id: Id2d081b61828352c998e517127132f883a20b7ef
- Remove 'oneway' from IHdmiVendorCommandListener.
- Add flush() method to HdmiCecController.
- Use IoThread for HdmiCecController.
Bug: 18495592
Change-Id: I497f7b49e94dd4402058ecc89cb5b7a3d58bf1e1
When creating or renaming files on external storage, sanitize the
requested display names to be valid FAT filenames. This also fixes
a handful of directory traversal bugs.
Also relax logic around generating display names to allow any
extension which maps to the requested MIME type. Tests to verify.
Bug: 18512473, 18504132
Change-Id: I89e632019ee145f53d9d9d2050932f8939a756af
A recent change to seeking behavior altered the logic of
setCurrentPlayTime() (which is called when animations are first
started) to set the current animated fraction to 0 for 0-duration
animations. This fix ensures that 0-duration animations snap to
their end value (fraction == 1) instead, matching the behavior
prior to the seeking fix.
Issue #18542543 Animations with 0 duration stay in initial state when calling setCurrentPlayTime(0)
Change-Id: I9916d962cf46453a9e3e1207f58baf16f4a5830a
- Decouple condition requests from expansion, now
pre-request when zen panel unhidden.
- Animate zen mode panel expansion.
- Improve default selection logic, ensure something
is selected as soon as we are in the expanded state.
- Tweak visual spacing.
- Map null condition to Indef properly when we start
out in zen.
- Avoid unnecessary condition teardown when the conditions
are updated but unchanged from current.
- Cap number of optional conditions to display, default=3.
Bug: 18335618
Change-Id: I007b7c3b2e75e2b42805af240684aa8581e9951a
- Make the system internal ringer mode change signal available to
other system components via a standard intent, instead of a
volume-controller-only binder call.
- Update sysui to use new intent for icon policy.
- Add proper muting state to the volumizer, to look more like
the associated volume panel slider.
- Add basic ringer mode state tracking for the notification-ring
slider setting.
Bug: 17899613
Change-Id: Ie2df52edb070055ef59c74039162a0e785d2fdbb
Previously, the computation was double-counting the left and top padding
because it was treating the third and fourth Rect.intersect() arguments
as width and height rather than right and bottom.
BUG: 18418091
Change-Id: I2ab669ee5060372ae11cfe804dcc05c7426be1ec
Currently, every CameraManager instance adds itself as a camera service
listener, which has the unfortunate side effect of keeping them all alive
indefinitely.
This is doubly unfortunate since every CameraManager keeps the Context it
was constructed with, and therefore may be leaking whole Activities along
with the CameraManager itself.
Break out a global per-process CameraManager which handles service
connection keepalive and availability listeners, so that local camera
manager instances can go out of scope as expected.
Bug: 18077200
Change-Id: I1be5fb8d3492131e98bb4a84121400d4abb2b9e1
The display setting saved to disk were using a localized name for
the key. This is an issue if the user changes languages after the
display settings have been saved. We now use the non-localized
name for the display to access the settings if it is available,
else we fall back on the localized name.
Bug: 18190800
Change-Id: I837c06a8935df10727229a1aa2bb6eeb3953707f
When a client requests to update the LE transport MTU, the server
currently does not get notified and can therefor not properly size
notifications appropriate to the current MTU.
Bug: 18388114
Change-Id: I515bfc2cc9846490d57de71860f41ea9a61fa243
Incorrect implementation that broke the Brightness dialog slider. Reverting
to the previous behavior.
This reverts commit c5c9d0af764f590ae0031b5470192a0a08ca42d1.
BUG: 18510040
Change-Id: I201b1da46be964fcf6f041bb92ef79c335c2d23d
The current heuristics depend on devices being alive at midnight+ in
order to run periodic background fstrim operations. This unfortunately
means that people who routinely turn their devices off overnight wind
up with their devices *never* running fstrim, and this causes major
performance and disk-life problems.
We now backstop this very-friendly schedule with an increasingly
aggressive one. If the device goes a defined time without a background
fstrim, we then force the fstrim at the next reboot. Once the
device hits the midnight+ idle fstrim request time, then we already
aggressively attempt to fstrim at the first available moment
thereafter, even if it's days/weeks later without a reboot.
'Available' here means charging + device idle. If the device never
becomes idle then we can't do much without rendering an in-use device
inoperable for some number of minutes -- but we have no evidence of
devices ever failing to run fstrim due to this usage pattern.
A new Settings.Global element (type 'long', called
"fstrim_mandatory_interval") is the source of the backstop time. If
this element is zero or negative, no mandatory boot-time fstrim will
ever be performed. If the element is not supplied on a given device,
the default backstop is 3 days.
Adds a new string to display in the upgrading dialog when doing
the fstrim. Note it is too late for this to be localized, but since
this operation can take a long time it is probably better to have
it show *something* even if not localized, rather than just sit there.
Bug 18486922
Change-Id: I5b265ca0a65570fb8931251aa1ac37b530635a2c
Add a state callback so lockscreen reports back whenever its state
relevant for PhoneWindowManager changed, instead of synchronously
calling into SysUI which can lead to deadlocks. Directly use
LockPatternUtils for isSecure, and optimize the number of calls to
this method to optimize layout performance.
Bug: 17677097
Change-Id: I5d491fc8884d4f84d9562626b9ea0d5eaa5166fc
