The status bar and navigation bar are two completely separate
elements, with their own semantics. The system bar now classifies
itself as a navigation bar, since that is really how it behaves.
This required rewriting the HDMI resizing code, so that it is
all done by PhoneWindowManager since that is what is responsible
for the size of the navigation bar (and thus now system bar). This
actually gets rid of a fair amount of code, and means we can also
do the same thing for a pure navigation bar.
Likewise the system bar now has the navigation bar ability to be
hidden when requested by system UI flags. To get the behavior
we want on Xoom, we only allow the nav bar to be hidden when it
will help provide a better aspect ratio for showing widescreen
videos.
Finally the nav/system bar now animates when hidden and shown.
Change-Id: Ie927154b68376a0b61802f99171ff56b8da92e7a
- fix bug #6163772
- use bits field and pack them as much as possible
- take care of "supportsRtl" flag from Manifest
- add visual unit tests
CTS unit tests in another CL
Change-Id: Ib77c4eb423854209af130688c5ef9977401a9c1c
Some views (such as ImageView and TextView) handle non-opaque alpha
values directly. This was originally an optimization, but we can handle it faster
in many cases without this optimization when DisplayList properties are enabled.
Basically, if a view has non-overlapping rendering, we set the alpha value directly
on the renderer (the equivalent of setting it on the Paint object) and draw each
primitive with that alpha value. Doing it this way avoids re-creating DisplayLists
while getting the same speedup that onSetAlpha() used to get pre-DisplayList properties.
Change-Id: I0f7827f075d3b35093a882d4adbb300a1063c288
- introduce "supportsRtl" as a new application attribute in the AndroidManifest
- "supportsRtl" default value is FALSE (no RTL support)
- adapt the View layoutDirection and textDirection logic to take care of "supportsRtl" value
Change-Id: I5e4f9f576e14f35dedc6b0c29a7142c397f598e0
Re-enabling DisplayList properties last week caused some app
errors due to the way that some transforms were being handled (specifically,
those coming from the old Animations and ViewGroup's childStaticTransformation
field). This change pushes *all* transform/alpha data from View.draw() into
the view's DisplayList, making DisplayLists more encapsulated (and correct).
Change-Id: Ia702c6aae050784bb3ed505aa87553113f8a1938
Use it for recent tasks switching.
Not perfect yet by far, but something.
Also fix issue #6186758: Twitter crashes after tapping on a tweet on JRM75D
Change-Id: I49bf6c94aafde875ac652dedaf96d6c08cc9e7d2
This should work properly for crashes. It currently doesn't do the right
thing for ANRs since, in a lot of cases, they seem to happen asynchronously
_after_ the testcase has ended. Will try to improve that behavior with a
subsequent change.
Bug: 6128185
Change-Id: Ie535141e879062c11ee7108b37d282a33a5b5eef
Also creates a special TestRunner which runs one app per testcase. Note that
running the smoke tests with android.test.InstrumentationTestRunner will /also/
work, but will run all of the launchable activites in a single testcase called
testRunAllActivities.
Bug: 6128185
Change-Id: Iffedff7e6105bbca614778a4d294d3be421f19d6
This change adds a v11 version of Fountain, as well as v11 and v14 versions of
RSTest. All tests currently build and pass on the required platforms.
This also fixes an initialization bug for RSTest running on older devices.
If we don't directly initialize "each" component of the vector types, it can
result in uninitialized memory (or zero) being used for divisors (particularly
with the char vector types). This triggers SIGFPE with the latest pending
Clang/LLVM rebase.
Change-Id: I92a70c2aeed4e20f110b1cb24ee926fc27be9dbb
* removed some unused parameters
* removed obsolete live website test harness
* updated test class so that mean suite time for page cycler
is emmitted via instrumentation status
Change-Id: Iccb40f70a62a4ac9b8d5bceab9a6a715c611c573
Splits interface and implementation; all client calls are forwarded
to an abstract WebViewProvider interface, and the existing implementation
moved into the WebViewClassic implementor of this interface.
Originally taken from a snapshot from the development branch, by:
git diff HEAD 9a4c328a54cc05e5 | git apply
- but then rebased to keep up to date with master
Interdepends on webkit and Browser changes:
https://android-git.corp.google.com/g/158979https://android-git.corp.google.com/g/167911
Change-Id: I91403f32654ff308934e95c832d17b292a7d9b2e
This change introduces a few new bits of data on
Notification that will help the Notification Manager and
System UI route and display them more intelligently:
-> priority: an integer in a predefined range that
indicates the app's best guess as to the relative
importance (to the user, right now) of that information
-> kind: a tag (really, set of tags) indicating the general
type of notification (realtime, asynchronous, etc)
-> extras: a Bundle of additional key/value pairs
associated with this notification (currently @hidden)
The notification manager takes these data into account when
assigning to each notification a score which is passed with
the notification on to the system UI, where it can be used to
affect presentation. For example:
- Spammy apps (identified explicitly by the user or by
some other means) will have their notifications scored
very negatively by the notification manager, allowing
the UI to suppress them
- Notifications of higher score might be shown larger
or in a different way
- Very important notifications (indicated by a very high
score) might interrupt the user during an otherwise
important task (videochat, game, etc)
Implementation note: This replaces/extends the old internal
notion of "priority", which was mostly used to organize
ongoings and system notifications at the top of the panel.
Change-Id: Ie063dc75f198a68e2b5734a3aa0cacb5aba1ac39
When a drawPath command is recorded in a display list, a copy of the
source path is made to preserve against possible modifications of the
said source path. Copies are discarded when a display list is cleared,
which usually happens on invalidate(). This means that even if a path
is never modified, the texture generated to draw it on screen is
destroyed every time an invalidate() is issued. This change fixes this
problem by introducing a reference to the source path in the copy.
If both the copy and the source path have the same genID, they are
the same path and can share the same texture.
Change-Id: I34849311c183e06336a1391d2d1568a087f973f6
