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
We introduced some new flag at the lowest significant bit of the
battery level int but failed to account for it when unpacking.
Bug:25596467
Change-Id: I4320e6fcc208ec6de249b14fe3e399ab2f32d839
java.lang.IntegralToString is being removed, replaced
all its usage by com.android.internal.util.HexDump.
Bug: 24932279
(cherry-picked from 15fc0548a536750110e159e06a39ba943eccdd81)
Change-Id: Id6ab88337af12d93cd73c41775b9d5baa1e61d96
Standard launcher can be uninstalled for system user. A low priority
placeholder home activity is used to make sure the system can always
boot. By default the component is disabled for all users, and is only enabled
for the system user at boot time.
Bug: 25726710
Change-Id: I97eed02c9e2bbd69a737cc1d203110bed837b803
The ephemeral provider is a service that simply determines whether or
not an ephemeral application is available. The ephemeral installer
does the heavy lifting of installing the ephemeral application.
Bug: 25119046
Change-Id: I591f4c2c3f2b149d299fa8b4f359f2582d9199cb
Traditionally, when a view called requestLayout it would force
recursive requestLayout calls for all parent views up the
hierarchy. This meant that there was no way to determine at traversal
time whether a parent view itself needed layout, or if just one of its
descendants did.
Add a ViewParent method requestPartialLayoutForChild(View). This lets
a caller state that a particular child of a given parent needs a
remeasure and relayout at its current measured size and position
within that parent. This can help prevent the full-tree relayout often
caused by otherwise trivial changes. Partial layouts are processed
after any pending "full" relayout during ViewRoot traversals, but
before drawing.
Add a ViewGroup method requestLayoutForChild(View). This lets a
ViewGroup decide whether it is more appropriate to request a
traditional relayout or a partial layout for itself or just the child
that changed.
Add a ViewParent method findDependentLayoutAxes. This allows a caller
to check if the ViewParent's layout is dependent on a specific direct
child view along one or both axes. Called recursively, this can be
used to determine if a change in a child view can be isolated to a
partial layout, even if its direct parent's own layout is tied to its
other ancestors. (e.g. MATCH_PARENT, LinearLayout weights)
Implement ViewGroup#requestPartialLayoutForChild to call new
ViewParent method findDependentLayoutAxes and based on the result,
either request a full layout for itself or a partial layout for the
child in question.
Implement findDependentLayoutAxes for common framework ViewGroups. A
private implementation in ViewGroup is available for use by framework
classes that will deal with basic LayoutParams. These implementations
specifically check for derived LayoutParams classes and abort the
optimization if they find something beyond their expected parameter
types.
Change-Id: I0a1a9b79293d17d4fae8d9892b96d3586f9401ae
