The APIs are:
* setting a listener for the area of the caption where we display
control buttons; this is intended for apps that overlay the caption on
their content, so they don't display the content in that area and clash
with the buttons;
* specifying the color pallete of controls in the caption; by default we
try to infer the best color from the theme (dark buttons for light theme
and vice versa), but in case we get it wrong, we allow the developer to
overwrite it;
* specifying the caption background during the resizing; by default we
try to infer a good color from the theme, but in case we do it wrong, we
allow the developer to overwrite this.
The CL also includes merging of layouts decor_caption_dark and
decor_caption_light into a single one. Not only it reduces code
duplication, but also is necessary for allowing adjustment of the
controls color pallete after the layout was created.
Bug: 25486369
Bug: 25818398
Change-Id: Ib87fe849b07df341893ec7873982bf7ab932f6d5
This reverts commit c55d5072ac.
There were several bugs related to incorrect handling of various
layout issues (layout not being run on containers/views that needed
it), reverting to take another run at it outside of master.
Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view
Change-Id: Ic0e159cbcf6171652d8fd1bee9ae44a3977cea04
This modifies the existing rigid background restriction to
a more moderate policy that we can (eventually) apply to all
apps:
- After N minutes no longer in the foreground, any background
services running in the app are stopped and no more can be
started.
- No manifest receivers for the application will be executed
if the broadcast is not being sent explicitly to that app and
the app is not running. (Eventually we should tighten this so
they won't be received if the app is past its N minute
background window.)
- Other non-background processes may still bind to services in
the background process, which will raise it to back to an
executing state... so things like syncs, jobs, live wallpapers,
accessibility services, etc still work.
Change-Id: I08ddbfdf640ef324a27b2eb9eecd9499f3ebddd9
This is useful when using the new AlarmManager direct callback
interface to wake up the system and request that an object whose
API consists of messages (such as a StateMachine) perform some
action.
In this situation, using AlarmManager.onAlarmListener by itself
will wake up the system to send the message, but does not
guarantee that the system will be awake until the target object
has processed it. This is because as soon as the onAlarmListener
sends the message and returns, the system is free to go to sleep
again.
Bug: 20157436
Bug: 25823676
Change-Id: Idff20029d287f26347441a2523b7fb20eda6a8b0
Status bar will also show a different badge icon when managed profile
is in quiet mode i.e. work mode is off. The tile is invisible for now
until the full feature lands.
Bug: 22541941
Change-Id: I53f33ea346cd9215ecee2ca42de137af61e4c8a2
Previous CLs [1][2] introduced an opaque navigation guard view to
avoid the island effect (the real nav bar is transparent but the IME
shows its UI with assuming that the real nav bar is opaque).
[1] I460912ee7c117480c57b947ed31eca330819f32c
[2] I6a93f30aec83f1cecfb854073046cbc87ab4aa66
Although the current guard view works fine for that particular case,
there are two major situations where having an opaque navigation
guard view does not make much sense.
1. The IME shows no software keyboard at all.
Some IMEs automatically hide software keyboard when a hardware
keyboard is attached.
2. The IME relies on floating UI that is disjoint from the bottom of
the screen.
The main goal of this CL is to address case 2 because unlike case 1
the system is not able to automatically detect the case 2. Only IME
developers know when the opaque guard view should be opted out.
Of course, if IME developers can opt out the opaque guard view,
it means that they can also work around case 1 without relying on
the system, but again it is not the primary goal of this CL.
With this CL IMEs are now able to opt out the opaque navigation guard
view by calling Window#setNavigationBarColor(Color.TRANSPARENT) from
InputMethodService#onWindowShown(). Note that this API used to have
no effect for IME, hence reusing this here should have no compatibility
issues.
Note that any other color is currently ignored to minimize the impact
on UX.
Bug: 22564251
Change-Id: Iea77915ecc55eedaf19899e72c44f704ba9d852c
To make sure there is always enough contrast between the status bar
icons and the background, we move the drawing for the status bar
background into BackdropFrameRenderer while resizing, so we can
extend the width into the full surface width.
Bug: 24365214
Change-Id: Ifbb10bacf66670c3637f6f6730a8ac47eb1c3939
So we don't have to implement crazy magic when one app requests
drawing the status bar by itself, and the other doesn't in split
mode.
Bug: 24365214
Change-Id: I1f6a0efd0865b784402055e008da2f31e626f163
* Add a new --ephemeral argument to 'adb install'
* Add plumbing to internally track ephemeralness
* Create new app directory for ephemeral installs
Bug: 25119046
Change-Id: I1d379f5ccd42e9444c9051eef2d025a37bd824fe
This allows us to tell lock checks from FBE checks separately,
and will be useful when dealing with password unification.
Change-Id: Ifbea425f749fee4d6d51faddd8b64bf717a1a5f8
My previous CL 92280cd309 [1] had a silly
mistake that "tl" is converted to "fil" but "tl_PH" is not.
[1] I94f203bddceb9c87710cb187cc3cc0ee6d9092a5
With this CL, the compatibility rewrite-rule from "tl" to "fil" starts
working regardless of the existence of countly/variant subtags in locale
string. So far the only affected platfrom is API Level 23.
Bug: 20696126
Change-Id: Ica9cd2baac002c406f92331aadd7725d7424046a
This patch updates the FloatingToolbar to look and transition
exactly as described in the UX spec.
It includes an animating (VectorDrawable) overflow button and
menu item buttons that sit in place during transitions.
Bug: 24257588
Change-Id: I2b3f84ba451800830878667ce1abd7a99b4f9fea
Now that the activity manager keeps track of per-uid process states,
we can push that already rolled-up data into battery stats to directly
track the times in those states.
The problem with the reporting was actually that we weren't dealing
correctly with negative process states, which is now fixed. (It was
interpreting them as FOREGROUND rather than not running.)
Also split out a number of new states -- TOP, FOREGROUND_SERVICE,
TOP_SLEEPING -- from FOREGROUND. This should allow us to get a much
better idea of how much an app has been actively in use: TOP is when
it is directly visible to the user or in use by such, FOREGROUND_SERVICE
is when it is running in the background in a way the user is aware of.
Also when reporting these numbers, they are no longer added together as
reported but kept as separate times.
Change-Id: I6d307503a4b4ad5c0d5d49305ef63f8eb858e2c9
If there is an image instead of applying the same
margin everywhere, the text now floats around the
image.
Change-Id: I87f9ca9f51fb270b0732a99374544381bd1fc4e0
This is a mechanical replacement of Context.getSystemService(String)
with Context.getSystemService(Class<T>) when retrieving InputManager.
Note those are bundled code. Hence we don't need to make sure
Build.VERSION.SDK_INT >= 23.
Change-Id: Iee47e374e1349720e3100bab33ed139e1f47c169
Refactors the menu helper classes. Both classes now implement a common
MenuHelper interface, which eliminates the need to keep separate helpers
on PhoneWindow and unifies the DecorView showContextMenuForChild()
implementations.
We now explicitly dismiss any previously shown context menu before showing
a new context menu. Previously we relied on the modal nature of the dialog
context menu to prevent multiple menus from being opened at once, but this
is no longer reliable with popup context menus.
Bug: 25656520
Change-Id: Idab3daa6d6888f803f2e33660fe1dd488e4c28d1
As a preparation to fix Bug 25373872, this CL introduces an additional
int parameter into the following two methods
- IInputMethodManager.startInput()
- IInputMethodManager.windowGainedFocus()
so that IMMS can know why IMM needs to start input. Currently the
"startInputReason" parameter is used only for debug message only when
the OS is rebuilt with flipping IMMS#DEBUG to true. Basically this
should have no impact in production builds except for a tiny overhead
of having one int parameter in some internal IPC calls.
Note that since 7663d80f6b [1] basically
IMMS#windowGainedFocus() has been a superset of IMMS#startInput().
Hence we should pass to "startInputReason" parameter to
IMMS#windowGainedFocus() as well as IMMS#startInput().
[1]: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
Bug: 25373872
Change-Id: Ia1fe120af7d71495c5f3a4fc0ec6390efb8240ca
We need a more sophisticated touch handling to support overlaying the
caption. The touch events need to be routed in following order:
close/maximize buttons, application content, caption dragging.
Bug: 25486369
Change-Id: I9d4e971fb055c217c0bd83f0490fb42a5c22e93b
Previously the dismiss callback was called immediately after the menu
received a close request; however, the dismiss callback implies that
the menu's window has finished animating and been removed from the
window manager.
Also cleans up handling of mPopup in MenuPopupHelper to prevent
unnecessary MenuPopup allocations and convert unnecessary fields into
method arguments.
Bug: 25323707
Change-Id: I8e3877ae6c40b4d0f1df23a4ff4fa48a7df34e0d
