I am not sure if this is the correct approach to the problem. Right now
we are reporting double chin (60 vs 30). The reason for this is that
we setDisplayPadding from Clockwork Home activity (bottom=30) and add
windowOutsetBottom.
We use display padding to set surface frame size (320x320) and both
outset bottom and display padding for inset. I think we should use only
one of these. I decided to go with display padding, because that's
what was suggested to me the last time I visited this. I removed
the dependency on windowOutsetBottom altogether.
However, I don't feel confident this is the correct way to do this.
We depend on Home activity to send the display padding now to get
the correct result, so wallpapers behind other activities will not
work correctly.
Maybe instead of setting display padding from the outside, the
windowOutsetBottom should be added to display padding bottom for the
purpose of calculating surface frame and generating insets.
Advice on what is the right approach here would be greatly appreciated.
Bug: 19881056
Change-Id: Ifb655528d8f85ef01d942bf1e64e8b08475689ca
- Downtime: Allow user to enter downtime early, offer as an end
condition four hours before downtime starts. Available in
either none or priority, regardless of settings configuration.
- Downtime: Always exit before next alarm if zen=none.
- Downtime: Make more like any other condition provider, remove
special status (mostly).
- Downtime: New auto-triggering rules, allow triggering after a
manual condition ends, once.
- Decouple NextAlarm + Downtime providers, allow them to offer
their conditions at the same time.
- Downtime/NextAlarm: Update conditions if they change while being
requested, even if unsubscribed.
- Make all three built-in condition providers optional, via config.
- New internal helper for runtime config.
- Don't follow changes to next alarm, consider the condition false.
- Isolate downtime calendar logic into separate class (for testing).
- Allow a:bb -> a:bb as a valid downtime range (all day).
- Volume dialog: configuration establishes maximum number of visible
conditions, including built-ins.
- Zen mode panel: avoid widget updates during layout transition.
- Zen mode panel: move controller callers to background thread.
- Zen mode panel: hide/show/rebind rows instead of adding/removing.
- ZenLog: Add downtime autotrigger results.
- Volume panel: Smarter refresh on ringer/zen changes.
Bug: 16373455
Change-Id: I4f801018ddb0beb6eb9fa03a81c79f7949888a3f
- 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
Reduce how much stuff ProcessStats spews, and do collapsing of
repeated intent filter targets when dumping IntentResolvers.
Also add to pm's checkout output to include shared user ids,
and fix output formatting in a few places.
Change-Id: Ic9fc6731f0439101ba9343535e66cdbbad47e291
The 24 hour setting was not respected correctly. Also
fixed a bug where the next alarm would not display itself
in the QS panel.
Bug: 16239208
Change-Id: I89734f783912dead5831db49db53fba04dbf54ee
Windows with FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS were
getting an incorrect content inset hint, because the
hinting didn't see the adjusted systemUiVisibility.
Also adds hinting for the stable insets.
Bug: 17508238
Change-Id: If9647277feb6811b15665b801accd896c51dbd12
Adding the new structure was making it difficult for
LMP devices to have common source with upcoming API version.
Fixes bug 17008504
Change-Id: I704503cf0ebff113874c87ab11e37735dbe7b8d7
This change incorporates API council feedback and enables the
TrustAgent whitelisting API.
It also contains a minor cleanup of DPM's use of UserHandle
to eliminate unnecessary object creation.
Fixes bug 17008504
Change-Id: I63cc50169fde54b34406845818bcaf6aadc1a3db
- If the user's next alarm is in the next 12 hrs, provide
this as an exit condition trigger for leaving none/priority.
- Don't display the next alarm condition when downtime is active.
- When the next-alarm exit condition is active, follow changes
to the next alarm, assuming it remains within the 12-hr window.
- Tweak the downtime condition strings to be consistent.
Bug: 16373455
Change-Id: I4020b91d323dead998e62d655132eca07438b148
Implement two-line exit conditions, display the duration + end
time on separate lines.
Bug: 16824863
Change-Id: I8dabc83042fce604ccb86b463b9bb547c7903c64
By default, dreams should not get the in-window bars
because those conflict with the lights-out bar mode.
Bug: 17367264
Change-Id: I8c041c706f7a7c4791ed4760c34a5618fb7423d7
Decouple events from alarms in the zen interception function,
and default the new allowEvents to true.
Bug:17580878
Change-Id: Iff10df385206ad73c3423ff118c79e94a10918d9
For multi-user the issue was looking into the user ID of the current
process instead of the active user. The current process was the system
process and the call to UserManager was returning a user handle that
wasn't of any use while trying to map sound models to a user.
For language, the issue was that we were incorrectly just looking up the
model based on the keyphrase id, however we should have also taken the
enrolled model's locale into account.
Explicitly document that for model management the string representation of locales
is a BCP47 language tag.
Remove debug logging.
Bug: 16798166
Bug: 17462570
Bug: 17463511
Change-Id: Ieffb3e218de63f6e7f40af9705dced481a35b0ad
On some devices, we want the screen off transition to complete before
we start dozing. Added a new config.xml attribute config_dozeAfterScreenOff
to configure this behavior.
Defer starting dreams until the display is ready.
Fixed some minor issues in the system UI doze service when setting the
display state.
Bug: 16187655
Change-Id: Ib1bc60de5457166f4b4880732db5df989dda67a4
This should not break any apps as this API has been marked
@removed more than a week ago.
Bug: 17425123
Change-Id: I19d7e933a3f2a59e1b406a9f87d272f058a13e0d
Issue #17394151: WallpaperService / Engines need to get notified
of WindowInsets
Issue #17394203 Wallpapers need a system API to be shifted in order
to support burn in protection
Adds a new API on WallpaperManager to set additional offsets to
make wallpapers extend beyond the display size.
Insets are now reported to wallpapers, to use as they may. This
includes information about the above offsets, so they can place
their content within the visible area. And to help with this, also
expose the stable offsets APIs in WindowInsets which is also very
useful information for the wallpaper.
Another new API on WallpaperManager to set a raw offset to apply
to the wallpaper window, forcing it to move on the screen regardless
of what the wallpaper is drawing.
Fix wallpapers when used with overscan enabled, so they still extend
out across the entire screen. Conveniently, the above new window
insets information is very useful for this case as well!
And a new wallpaper test app for all this stuff.
Change-Id: I287ee36581283dd34607609fcd3170d99d120d8e
