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
