There was a mistake in the code that was supposed to recover from the
initial time on a new device being bad until the real time ultimately
gets set, which was causing us to update the start clock time every time
there was a time change (instead of just when the original start time
appears bad).
Rework all of this, so we now count the start time as bad if it is more
than one year before the current time, only modifying it in that case.
Also when modifying it, adjust the time we set it to take in to account
how much realtime has actually elapsed so far in the battery stats.
Change-Id: If74bd711d9b7618c8f6148a9935c452aaaa7e257
Previously we tried to read /d/wakeup_sources to gather kernel wakelock data. If that
fails we used the older sys file /proc/wakelocks.
N7 has both /proc/wakelocks and /d/wakeup_sources, but /proc/wakelocks
has the actual data we need. All other devices are using /d/wakeup_sources, so
only N7 experienced a loss of kernel wakelock data.
The original regression was introduced here: ag/659258
Bug:22556242
Change-Id: I51ec68e957f587bc1466e24f0a1dbc8cd7753ac6
- Add onFingerprintAcquired, so Keyguard can grab a wakelock to prevent
the device from sleeping.
- If we get a successful fingerprint, wake the device up, immediately
dismiss the keyguard and tell PWM that we kicked off our frame that
will represent the correct state.
- PWM then waits for this frame to be drawn, and then turns on the
screen, which results in unlocking directly to the previsouly
opened app.
Bug: 21855614
Change-Id: I5f43df17fa5e4e9c6a6392eef4a4590b07df4f96
...context and/or screenshot
Added new API to find out what contextual data has been globally disabled.
Also updated various documentation to make it clear what kind of contextual
data you will get (and when it will be null).
Also added a new Activity.showAssist() API because... well, I was already
in there, it was easy to do, it is safe, and maybe people will build cool
things with it.
Change-Id: Ia553d6bcdd098dc0fce4b9237fbfaca9652fc74b
Simplify ChooserTarget handling by requiring a target component and an
extras bundle instead of a full PendingIntent/IntentSender. This
simplifies the handling of URI grants from sending apps.
Prune ChooserTargets that point at ComponentNames that don't share a
package with the original matching Activity target or that aren't
exported so that we don't show the user something they can't launch.
Bug 22516282
Change-Id: I3439c0910b4fa4f95c7a881b529942c96ffc953e
Add new option to startActivityAsCaller() which allows you to
specify that we should not do security checks on the target
activity being launched.
Change-Id: Ie6b28807b96fef35ccdff93b0a01066cfd8fa307
This CL addresses TODOs in Ib641dda49f7ab1c7d60207c36a47767bb408.
With this CL the position of PopupWindow is always specified in
window-local coordinates even if FloatingToolbar#mParent is not a
decor view.
Bug: 22335001
Change-Id: I0cdd63a00051fa30981e517c07682075467ac598
This is a coment-only follow up CL for I71a8d356e868dc7715b030ca,
which wrongly changed coordinates from window-local to view-local
(relative to FloatingToolbar#mParent) when showing PopupWindow.
The position of PopupWindow still needs to be specified in
window-local coordinates as we had done before
I71a8d356e868dc7715b030ca1078da4ec39368c3.
Currently the problem might not be visible to users because
1. FloatingToolbar is not a public API hence all the instances
are under our controll.
2. FloatingToolbar#mParent is alwasy initialized with
PhoneWindow#getDecorView() for now.
Bug: 22335001
Change-Id: Ib641dda49f7ab1c7d60207c36a47767bb408971c
New APIs allow the voice interaction service to set/retrieve a filter
for which of the show flags are allowed.
Change-Id: I588cbe55afee0548ad3afa22d3a7d3bc43cb54a6
..."FATAL EXCEPTION IN SYSTEM PROCESS"
Synchronous calls out of the system process are bad, m'kay?
This should be a safe change because the only place I see calling
this interface are within the system process where there is clearly
no other dependency on ordering.
Change-Id: I483b07cfd68d00d74797784c2a75012e8dd67141
- New screen on app op to record the last time each app has
caused the screen to be turned on.
- New battery stats event that tells us the reason the screen
has been asked to turn on.
- Propagate out power manager API to specify the reason a caller
is asking to have the screen turned on.
Note that currently the window flag to turn the screen on bypasses
much of this because it is being handled in the window manager by
just directly telling the power manager to turn the screen on. To
make this better we need a new API where it can specify who it is
calling the API for.
Change-Id: I667e56cb1f80508d054da004db667efbcc22e971
In previous platform versions, finishing an action mode would clean up
the current action mode even if it was not the same ActionMode
instance. Some common shared code inadvertently relied on this
behavior, so stay bug-compatible with it based on targetSdkVersion.
New apps will get the stricter behavior.
Bug 22265882
Change-Id: Id5d6341aefc07a3cb788d5d6d0b531816f761e42
High cpu times are expected as multiple cores can be running at the
same time, so comparing against the time between samples is incorrect.
I am reasonable certain that the values we see now are correct, so disabling this
check. However, checking for negative values (overflows) is still enabled and
will remain enabled because there is no case where we will be ok with negative deltas.
Bug:22461683
Change-Id: If9c7cdbb75ceaed059d1e0f4dd83cfdd3e021a93
Currently PopupWindow used for the floating toolbar specifies
neither FLAG_LAYOUT_NO_LIMITS nor FLAG_LAYOUT_IN_SCREEN.
As a result, the floating toolbar can overlap the selected
text when the attached window does not have enough height.
Here is the repro code.
final TextView textView = new TextView(this);
textView.setLayoutParams(
new ViewGroup.LayoutParams(
ViewGroup.LayoutParams.MATCH_PARENT,
ViewGroup.LayoutParams.WRAP_CONTENT));
textView.setText("A test sentence.");
textView.setTextIsSelectable(true);
final AlertDialog dialog = new AlertDialog.Builder(this)
.setView(textView)
.create();
dialog.getWindow().setGravity(Gravity.BOTTOM)
dialog.show();
If you tap a word in the dialog, the floating toolbar
unintentionally overlaps the selected text due to the limited
height of the AlertDialog.
It also turns out that just calling
PopupWindow.setClippingEnabled(false)
to specify FLAG_LAYOUT_NO_LIMITS is not sufficient and ends up
showing the toolbar on the NavBar because we have mistakenly
compared bounds in window-local coordinates
(e.g. FloatingActionModemContentRectOnWindow) with bounds in
screen coordinates (e.g. FloatingActionMode#mScreenRect).
Hence the confusion of window-local coordinates and screen
coordinates in FloatingToolbar and FloatingToolbar also needs
to be addresses.
To summarize here are the notable changes in this CL:
- Specify FLAG_LAYOUT_NO_LIMITS so that the floating
toolbar can be placed outside of the attached window.
(We do this with PopupWindow#setClippingEnabled)
- Switch to use screen coordinates from window-local
coordiantes in FloatingToolbar and FloatingActionMode
because some system components such as WindowManager
prefer screen coordinates.
- Put -OnScreen suffix for Rect and Point variables
as long as they are in screen coordinates.
Bug: 22335001
Change-Id: I71a8d356e868dc7715b030ca1078da4ec39368c3
Activating the assistant will now route through SysUI, so
we have the logic whether to start an activity or to start a voice
interaction session in one single place.
Bug: 22201770
Change-Id: I0f4699533aea2a1e595ee25a844434c82f548c01
