TextView is now much smarter about the text it reports, limiting it
to what is visible (plus a bit more). Also add a facility for it to
report where the lines of text are, both as offsets in the text string
and their baselines on screen.
Part of fixing issue #22328792: Fix scalability issues in AssistStructure
Change-Id: Idddb8c3a3331355f381e2d4af06d520fe7c7ce8e
...to an explicit toggle to enable in Settings
Add a new permission flag, saying the permission can be automatically
granted to pre-api-23 apps. Apply this to SYSTEM_ALERT_WINDOW.
Change-Id: I24a0ceabe7e9f5e458a864d30eda2696ad14a699
Just forgot to add the request to the active set.
Also eradicate a bunch of old cruft that has been replaced
by the final APIs, and improve voice interaction test to
sit fully on top of the final APIs and have a test for
command request.
Change-Id: Ieff7a6165ebf2a4c5fb80c1ebd020511a2ae63ee
...into account when calculating the position information
Actually what we need here is the full transformation matrix, if it
is available. And that means actually computing the location of
views on the screen requires doing this all through transformations,
so the AssistVisualizer has been changed to do this (while still
also keeping the old mechanism for comparison to verify that things
are working correctly).
Also added new properties for elevation and alpha.
And optimized the parcelling of AssistStructure to not write things
that aren't needed; this reduces the parcelled size by about half.
Change-Id: I50b0dd2e6599c74701a5d188617a3eff64b07d03
Bug: 22090564
These tests were not touched for at least 3 years, and with webview
moving to chromium, they are tested at the chromium side.
Change-Id: I4424871dd97c5dc23bb3dbdcee0915d5ab893c7e
Since 2 clip paths is taking the intersection as the final clip, we should
separate this test case into 2 groups.
Prior to M release, the 2nd clip path is overriding the first one.
The behavior changed in this CL:
e9c01a40a2f0f0da195dfbb2909aaee5c005d1c6
b/16376848
b/19946683
Change-Id: Ib21c95e70f1317321725acbbe0ccf91713f748c3
Since these alarms allow you to bypass the idle restrictions,
we don't want them to be so open-ended like other alarms. This
implements a policy where the alarm manager will only deliver these
types of alarms every X minutes to each application. For this
initial implementation, X is 1 minute under normal operation and
15 minutes when in idle mode.
To do this, I needed to introduce a new internal allow-while-idle
flag for system alarms, which applications can't get, and doesn't
have these new restrictions.
Also tweaked how the alarm manager handles the alarm window, so it
doesn't change if the alarm gets rescheduld; the window is now always
what as computed based on the time when the alarm was first
given to it.
Finally, fix TimeUtils to be able to correctly print times that
are > 999 days.
Change-Id: Ibad8c6a7c14b0624b54e82267be23224b4c31e84
SYSTEM_INTERACTION events are signals to the system for a package's
implicit actions (service bound, etc).
These should not affect the API visible stats like lastTimeUsed, etc.
USER_INTERACTION is for user initiated actions (notification interaction, etc).
Bug:21761781
Change-Id: I4585cf35fbb158612a3c737710108bec34e89183
Add new APIs to associate a Request with a name, get all active
requests, and get active request by name.
Also add a new Activity.onProvideReferrer() which will allow
applications to propagate referrer information to the assistant
(and other apps they launch) in a consistent way.
Change-Id: I4ef74b5ed07447da9303a74a1bdf42e4966df363
The framework API that takes a CharSequence as a prompt is now
deprecated, so update the test code to use the new API.
Bug: 21695917
Change-Id: Ic4b7afa6c547a9885a900ed092910f3c6bdd1dd4
Start moving Assist* stuff to android.app.assist.
Clean up some more of the VoiceInteractionSession APIs.
Clearly document that finish() is not the same as hide(),
always call hide() instead, and fix the finish() path to
also always do a hide to make sure everything is cleaned
up correctly.
Change-Id: I962d4069fcb34fe89547a95d395ae1b9fa3b4148
Let the intent receiver of a camea launch intent declare a prewarm
service instead of sending broadcasts.
Bug: 21347653
Change-Id: I11e31aad4f788ad90eb46a661b819d3e808ddb51
Devices on test benches are usually held sideways, which leads to app
rotation during launch. While it's useful to identify such issue from an
app perspective, the app compatibility test should be isolated from such
noise for the purpose of the testing for basic level of compatibility.
Change-Id: I403f96e5d8512ca6a17b05a83d69f4b02f760a32
Also rework how we transfer AssistContent and AssistStructure
to the assistant, so they are delivered as completely separate
objects rather than the kludgy bundling them in the assist
data thing.
Change-Id: Ib40cc3b152bafeb358fd3adec564a7dda3a0dd1d
Some apks includes widgets and does not have a launchable
activity. The inclusion of such apk for launching is an issue
with test configuration, not test failure.
Also logging intent used for app package for debugging purpose.
Change-Id: Ibca05757a401ea036e9910d8580d7cafd356567c
bug:14297149
SaveLayer's performance cost is high, and proportional to the surface
being projected onto. Since ripples (even unbounded ones) are now
always projected to the arbitrary background content behind them, this
cost is especially important to avoid.
This removes the last semi-secret, saveLayer from the projected
ripple implementation.
Also fixes the HW test app to correctly demonstrate this projection
masking behavior.
Additionaly, alters PathTessellator to gracefully handle
counter-clockwise paths, and simplifies the work done by
ShadowTessellator to ensure all of its paths are counterclockwise.
Change-Id: Ibe9e12812bd10a774e20b1d444a140c368cbba8c
decide if the app is still running after launch by checking
running tasks and look for a task with base activity belonging
to the package launched.
Change-Id: Ibb3894e765ccbca62f803decc3c1c1f36dc2d454
If the app tried to do various things with too much data --
starting an activity, starting a service, sending a broadcast --
this would fairly silently fail with little indication of what
was going on. Fix this in two ways:
- Now when the native code generates a TransactionTooLargeException,
it may include an additional message in it telling you how much
data was in the parcel being sent, to help you understand why
this happening.
- In all the framework code paths where we call to the system and
may fail, convert these failures into a a runtime exception and
rethrow them back to the app so that it will clearly get the
above message.
Change-Id: I745159b97d3edb6fca86aa09cbc40c1f15a7d128
This adds a new ActivityOption for the caller to ask the
system to track the time the user is in the app it launches,
delivering the result when they are done.
The time interval tracked is from when the app launches the
activity until the user leaves that app's flow. They are
considered to stay in the flow as long as new activities
are being launched or returned to from the original flow,
even if they cross package or task boundaries. For example,
if the originator starts an activity to view an image, and
while there the user selects to share, which launches gmail
in a new task, and they complete the share, the time during
that entire operation will be included.
The user is considered to complete the operation once they
switch to another activity that is not part of the tracked
flow. For example, use the notification shade, launcher, or
recents to launch or switch to another app. Simply going
in to these navigation elements does not break the flow
(although the launcher and recents stops time tracking of
the session), it is the act of going somewhere else that
completes the tracking.
The data is delivered to the app through a PendingIntent,
which includes the total time the app was in the flow along
with a time break-down by app package.
Change-Id: If1cf8892d422c52ec5042eba0e15a8e7e8f83abf
The tests use the new hidden Parcel APIs (if available on
the running platform) to emit statistics about ashmem usage.
Bug: 20153922
Bug: 20079551
Change-Id: I400d2a932f297e582c335389570f93c0d4a19fc9
This crashes while trying to run due to the '?attr/color1' reference inside
res/anim/blink.xml
Bug: 20817800
Change-Id: Ie3ea24ac9b22e69af152d6ffe87c8c953929299c
This happens when an app is launched but has a dialog shown on
top of it. Typical reason is a licensing prompt of sorts.
Change-Id: Id73f45f54767b869873c62f13aeeb470c1a5cd81
A previous CL introduced a new way of encoding view properties for
use by heirarchy viewer. This CL updates all views using the old
@ExportedProperty annotation to use this new method. The older
mechanism will be removed in a subsequent CL.
Change-Id: I6cc23b90cd9da1c6ce89b4caffe54874db203452
Hierarchy Viewer obtains the properties for each view by using
reflection and looking for fields and methods that have the
@ExportedProperty annotation. Using reflection made it quite slow
for large view hierarchies.
This CL adds a new method (encode) to each class that wishes to
export data to hiererachy viewer. Inside this method, the object
can write a sequence of key, value pairs corresponding to the
values it wants exported.
With this change, the dump hierarchy operation that used to take
more than 10 seconds can be performed in a few hundred milliseconds.
Change-Id: I199ac2e7ca3c59ebcfec7e6bd201e134c41fd583
