- Adds a trusted signal from Keyguard to PhoneWindowManager
- Allows PhoneWindowManager to exempt DISMISS_KEYGUARD windows from force hiding
- Allows PhoneWindowManager to dismiss Keyguard while occluded
Bug: 27410215
Change-Id: I3ad490b64a5805b6f3888a9f37fcfbdd0116395e
There is a known issue in the kernel uidcputime module that triggers
the WTF, which has a cost to the system. Convert to a regular log
instead.
Bug:28950306
Change-Id: I7cbb3138f644075f0d9d65ce8b52bd835eb270fd
Happens because CascadingMenuPopup calls setWidth() rather
than setContentWidth() like StandardMenuPopup does.
BUG: 30365568
Change-Id: Id850baaf1d9c5664220766e5e37869e2ec361a2d
DecorCaptionView is used in app view hierarchy in freeform mode
and it inherits default ViewGroup#shouldDelayChildPressedState
implementation, which returns true by default for compatibility
reasons.
This results in touch not delivered to child views in some cases
until there is movement or up action. E.g. touch on SeekBar will
not change the position of control instantly in freeform, while
it does in other modes.
This CL disables delaying child pressed state for DecorCaptionView.
Bug: 30037893
Change-Id: I4917143610b6c0d404d2395670de9525c10f2a6c
The platform currently supports the notion of default carrier apps.
These apps are set to DISABLED_UNTIL_USED until a SIM is inserted
which grants them carrier privileges, at which point they are enabled.
Apps are not touched if they have been updated from the version on
/system or if their state has been modified externally (e.g. by the
user).
This CL extends this notion to associated apps, which may not have
carrier privileges themselves, but should be enabled/disabled
alongside a particular carrier app. This should include helper apps
that should not be visible to users who don't use the given carrier
unless the user explicitly enables the app.
As additional protection, we add a check to ensure that we never
disable apps after the first time we've run. Since we need to store
this information in secure settings, we also move the call site from
PackageManagerService#main() to PackageManagerService#systemReady(),
which enables use of secure settings but still occurs before
third-party apps can be started.
Bug: 30141427
Change-Id: Iee72ba4e70e5ca97999c9147a65af82c670a23e8
Preferences lack a title on watch type devices due to lack of ActionBar
support. A custom ListView was added to use a custom wrapper adapter to
add a persistent header view at the top of the ListView that developers
would not be able to remove via the ListView API.
Bug: 27962897
Change-Id: I6bccecf85592d9507e0c7a04c9a035617001e9ef
For watch devices, AlertDialogs added the title and button bar as header and
footer views in the ListView. This broke compatibility, hence a solution to
overlay the panels instead with a wrapper layout.
Bug: 27482353
Bug: 30075032
Bug: 29833395
Bug: 29277843
Change-Id: I2ecbe56ae8f7d7e99c7ca2dad2a2092499212199
These appear as a new event in the battery stats history,
"longwake" in the long version and "Elw" in the checkin.
The power manager keeps track of which wake locks are held
for a long time and reports them to battery stats. Long
is currently considered 1 minute or more. Once it is long,
the start event will appear, and once if is released the
event will end.
In the case of a wake lock changing (typically its work
source changing), for purposes of this accounting this is
considering a pure release of the old state and start of
the new state... so the timer will reset back to one
minute until the wake lock is considered long. This is done
to prevent things that make lots of changes to wake lock
work sources from spamming the log.
Bug: 28753137
Change-Id: I33b6168c57a7ea6ea558273dec731704123124a5
Symptom:
When sharing an image from Album, ChooserActivity can be shown.
But then the app to be located to the bottom part of the list may not
be started even if user tap it.
Root cause:
ChooserActivity uses ResolverDrawerLayout. And ResolverDrawerLayout
can display only some items on the list (known as "Collapse mode").
When the item clipping along the bottom edge is tapped by the user,
ResolverDrawerLayout tries to expand the list and scroll it to a
better position, instead of starting an application.
In this problem case, ResolverDrawerLayout continues to try to expand
the list whenever tapping, so an application will never start.
Solution:
Change a condition so that mOpenOnClick becomes true only when the list
has been collapsed (mCollapseOffset > 0).
Bug: 30153542
Change-Id: I576fb6c8b6a91d79c1e0d46d069146779f4dbd17
Fixes an issue where LPU could no longer
be used on a non-looper thread even though
the looper is only used for a certain callback.
Now only using that callback mechanism is fatal
on a non-looper thread.
Change-Id: I2d766bd6c913e345ed6a3500b486263c8bc12b07
Fixes: 30076804
When checking for the credentials, we add a new callback
onEarlyVerified which gets called as soon as we know that the
credential was correct.
In KeyguardUpdateMonitor, we track the unlocked state of the user,
and if it's still locked, we slow down all the transitions to allow
for a more gradual unlock experience.
Bug: 29007436
Change-Id: I406d228f9f3e41e07fe3292a61df175a7f579e4d
Bug: 28615069
Tints the display at night automatically according to your schedule or
using the sunrise/sunset corresponding to your current location.
Change-Id: Ie56b4eed88cc2fcbae88002492b1edad5820b6b1
This allows the MIME type icons to be used in other system apps.
In this instance, the StorageManager app needs to show file icons
for a given file. By moving the icon mapping into a static library,
we can avoid duplicating the mapping and resources.
Bug: 29826961
Change-Id: Ic2dc7970cc5a5ca430e33425eb9f1ecbd733fe9a
With this CL, the system automatically grants a temporary URI permission
to the target application when the IME calls
InputConnection#commitContent() with
InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION. The temporary
permission will be revoked by any of the following events:
- InputContentInfo#releasePermission() is explicitly called by the
target application.
- The target application returned false in
InputConnection#commitContent().
- All the InputContentInfo instances copied from the original one are
GC-ed.
If we do not do this and there is an application that forgot to call
that method then there is no way for IME developers to prevent
permission denial from happening in the application except for relaxing
the default permission of the ContentProvider just because of such an
application.
Although application developers are still expected to explicitly call
InputContentInfo#{request,release}Permission(), forgetting to call
InputContentInfo#requestPermission() does not hurt the user anymore.
With this CL, calling InputContentInfo#requestPermission() after calling
InputContentInfo#releasePermission() is also allowed.
Bug: 29892936
Change-Id: Id955435dd2e72549ee7134f46b3c6951581694ad
This reverts commit c4b8f36de5.
Having InputContentInfo#requestPermission() should not hurt developers,
but we can polish the behavior in a subsequent CL without changing
the API.
Bug: 29450031
Bug: 29892936
Change-Id: I1b43c19417b643d0c269af860db2d309b73a90d5
It turns out that requiring editor authors to call
InputContentInfo#requestPermission() as needed is just confusing and can
cause compatibility issues, because if an editor author forgot to call
that method then there would be no way for IME developers to prevent
permission denial except for relaxing the default permission of the
ContentProvider just because of such an application. This is not what we
want to see.
My conclusion is that the system should automatically call
InputContentInfo#requestPermission() (or do any equivalent operation)
when InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION is
specified, like we have done in Context#startActivity().
With this CL, the system automatically grants a temporary URI permission
to the target application when the IME calls
InputConnection#commitContent() with
InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION, and the
temporary permission will be revoked by any of the following events:
- InputContentInfo#releasePermission() is explicitly called by the
target application.
- The target application returned false in
InputConnection#commitContent().
- All the InputContentInfo instances copied from the original one are
GC-ed.
Bug: 29450031
Bug: 29892936
Change-Id: I37fb744e4d3d1c59177fb0a9be4ef5c325c9a39f
Removed final from public sendMessage and sendMessageDelayed commands to
unblock unittest development. This allows tests to verify calls to
sendMessage and sendMessageDelayed.
Also fixed one checkstyle error with import order.
BUG: 28593024
Change-Id: I26e02c3d75049d385ded7891c4fc9967273c27be
TEST: builds
TEST: runtest frameworks-wifi
