Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Change-Id: I940433f601c6db998c1a8ffff338f5361200d5ed
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
For storing pointers, long is used in view/input classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Iafda9f4653c023bcba95b873637d935d0b569f5d
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in VelocityTracker class,
as native pointers can be 64-bit.
Change-Id: I8c454663a97745c7440bb6f99ef49d28e9026876
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
For storing pointers, long is used in MotionEvent class,
as native pointers can be 64-bit.
Change-Id: I88ebfef26070b7f49c14945cad37aa3db209ec90
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in KeyCharacterMap class,
as native pointers can be 64-bit.
Change-Id: Idc1b39874202e96b9231d7801e6707003787659b
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used as
native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I3c0855373c0e4bedc172adb82b103586de9219dc
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
Background padding should be used only and only if
- no padding is already defined into a layout file
- an explicit call to setBackground() / setBackgroundDrawable() has been done
Change-Id: I0a732c61b898e006ee86377bcbe7691740d68111
This change adds a new media router service whose purpose is to track
global state information associated with media routes. This service
publishes routes to the media router instance in application processes
and handles requested state changes such as selecting or unselecting
global routes. The service also binds to remote display provider
services which can offer new remote display routes to the system.
Includes a test application for manually verifying certain aspects
of the operation of the media router service.
The remote display provider interface is essentially a stripped down
media route provider interface as defined in the support library
media router implementation. For now, it is designed to be used only
by first parties to publish remote display routes to the system so
it is not exposed as public API in the SDK. In the future, the remote
display provider interface will most likely be deprecated and replaced
with a more featureful media route provider interface for third
party integration, similar to what is in the support library today.
Further patch sets integrate these new capabilities into the System UI
and Settings for connecting remote displays.
Bug: 11257292
Change-Id: I31109f23f17b474d17534d0f5f4503e388b081c2
When we dispatch input events into the actual application, make sure
the input invariants we rely on haven't changed. If they have, we
drop the event and log why.
Bug: 11399505
Change-Id: Id772e41ca41dc332bb02725ab486e3b10a73c220
Target the two biggest offenders:
- Coalesce keyguard setHidden(false) calls during unlock.
- Make sysui->WM call async.
Found during investigation into b/11221659.
Bug: 11221659
Change-Id: Icab48376bc356a933e0f9940bc2f924e2e77ab22
With the new tuned vsync offset, vsyncs are likely to occur shortly
after the input is received, meaning we will empty the input queue,
and thus won't schedule input consumption until more input is
received. If an application then speculatively posts draw commands to
the main looper faster than 60 hz, it will eventually end up blocking
in eglSwapBuffers. Since we're blocking in eglSwapBuffers, we won't
even schedule consumption until after the current frame (8-16ms), and
it's entirely likely we won't actually get around to consuming input
until after the next frame (another 16 ms of latency). This means we
can often go 16-32ms without processing any input events, causing
very noticeable amounts of jank.
Rather than waiting for the next input event to schedule input
consumption, speculatively schedule it every frame as long as we've
consumed some motion batch during this frame.
Bug: 11398045
Change-Id: I25e46308e00e9f9de00a1d8906f6b0e0f2e845b4
Background Drawable padding was not taken into account in RTL Locales
- make sure the Drawables are resolved before resolving padding
- during padding resolution take care about background padding
Change-Id: Ib0c722adf5341ab4fa2182a0d0ac2ca639e85cfc
Right padding was wrong for the LinearLayout with id/recents_linear_layout. Its value
was first correctly set by the fitSystemWindows(Rect insets) call but then was reset
to "0" during padding resolution.
Thus make sure that the initial values for user padding left/righ are also set to the
ones coming from the computed ones.
Change-Id: I60390ff7a24286a8f7214eaff8606cb76268ee90
IMEs recently gained the ability to layout out under the nav bar,
but our core measuring logic does not give height=WRAP_CONTENT windows
the entire screen height when computing desired window height.
Since IMEs can be identified by type, let them use the entire screen
height for measuring purposes, to properly handle the cases where
space is constrained, making that unaccounted-for nav bar height
important.
Bug:11215678
Change-Id: I1d0b73454c0c629e7d669b9de70641c7e8c4d333
A measurement optimization has exposed some apps that are relying
on incidental layout requests to have themselves update. With the
optimization enabled, these apps break.
Apps targetted at older versions of Android should not
break due to this optimization.
bug:11192311
Change-Id: Id5fc7f83ec2cb1541d3d0d16f951cd57c0afaccd
We have become too aggressive about not allowing windows to draw while windw
animations are running, basically not allowing any drawing in any window when
there is any window animation. So if you did a relayout while the status bars
were being animated, your window would stop drawing until that status bar
animation was complete.
This change relaxes those rules in two ways:
- A particular window will only be told to stop updating when *it* is
currently involved in a window animation. So animations in status bars
will not stop app windows from update, and vice versa.
- If a window receives input events while it is in the "do not update"
state, we will immediately terminate that state and start allowing it to
draw. If the user is actually interacting with a window, we don't want
to wait to show feedback.
Change-Id: I72574eec048aee53115b46a78686cf27f42c42f7
