ChromeView generates a large amount of such logs; while the real
root cause is being fixed, reduce the verbosity so other
interesting logs won't get overwritten.
Bug: 10871032
Change-Id: If42116671062d7b2cc2a13384424575da499c493
Move the projection surface to be a property of a DisplayList,
set to true for every background drawable.
Additionally, handle a projecting view background such that it doesn't
try to project onto itself (which is undesirable).
Change-Id: Ic70b17474bd87340e80767f8518f73b233419c7a
Not a complete solution, since we could be more efficient, but enough
to have both background display lists and proper invalidation.
Change-Id: I0216a104948c0930760275bb2b98318b0a4487e7
Applying insets is now handled by:
* WindowInsets class - Encapsulate system insets and local decor
insets into a single object, written specifically so that new inset
categories may be added later. Apps cannot construct their own
WindowInsets, only clone with optional modifications. This is to
prevent losing data in the event of new insets added in the future.
* onApplyWindowInsets - Actually perform the application of insets.
* OnApplyWindowInsetsListener - Allow an app to use a separate
Listener object to apply insets to a View. This allows for things
like support lib integration in custom views written for older
versions where the verifier would otherwise complain about the use
of the new WindowInsets class as a method parameter. It also allows
for applying insets in a custom way without writing a custom view.
* dispatchApplyWindowInsets - Dispatch the call to self and children
in turn, if applicable. An OnApplyWindowInsetsListener will override
the behavior of the view's default onApplyWindowInsets method; a
listener wishing to call down to the 'superclass' implementation as
part of its own operation should call view.onApplyWindowInsets. App
code should generally not override this method and instead override
onApplyWindowInsets or provide a listener.
Compatibility support with the existing fitSystemWindows method has
been provided in both directions: for code that previously called
fitSystemWindows on arbitrary views and also for code that overrode
the fitSystemWindows method in custom views. A view that supports the
newer onApplyWindowInsets mechanism should not mix that behavior with
other calls to fitSystemWindows or vice versa. Support lib-style code
should take care to consistently use one mechanism or the other at
runtime.
Change-Id: Ie88b96e0382beb5d3c3f6cd013f7043acbc0a105
First pass at API for cross-Activity Scene transitions.
Remaining work:
Transition back
Automatically capture hero element info
Transfer of surface texture to synchronize between Activities
Possibly use scene names to indicate preferred transition
Change-Id: I59d07de1fae694a46b92b1c82525daa301ec1377
Remove setFlags(), which doesn't seem to be used, and make the flag
declarations private. The flags can be set with hide(), show(), and
setOpaque().
Change-Id: I2bdff0881d9397b0c4455f6663c2a1e8084df719
IsContainedVolume -> hasIsolatedZVolume conveys that this affects Z
ordering of views
ProjectToContainedBackground -> ProjectBackwards, since it ended up
using its own projection target, separate from the 3d volume bit
Change-Id: Ia2cde838cc4da134366fe6ff623290fbd65e50c3
1. There are a few parcelable classes related to printing and accessibility
which are public but not added in the framework.aidl list so third parties
cannot write aidl interfaces that pass these classes. As these classes
are public it is resonable for devepers to be able to pass them between
processes.
Change-Id: I85da1de5198902b74f19d23e3fe16b45b4a11051
This a merger of two commits submitted to AOSP by
the following authors:
ashok.bhat@arm.com, david.butcher@arm.comacraig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com
Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.
Commit messages below:
================================================
AArch64: Make graphics classes 64-bit compatible
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.
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>
==================================================================
AArch64: Use long for pointers in graphics/Camera
For storing pointers, long is used in
android/graphics/Camera class, 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)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
===================================================================
Change-Id: Id5793fa0ebc17ee8b1eecf4b3f327977fdccff71
This a merger of two commits submitted to AOSP by
the following authors:
ashok.bhat@arm.com, david.butcher@arm.comacraig.barber@arm.com, kevin.petit@arm.com and
marcus.oakland@arm.com
Due to the very large number of internal conflicts, I
have chosen to cherry-pick this change instead
of letting it merge through AOSP because the merge
conflict resolution would be very hard to review.
Commit messages below:
================================================
AArch64: Make graphics classes 64-bit compatible
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.
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>
==================================================================
AArch64: Use long for pointers in graphics/Camera
For storing pointers, long is used in
android/graphics/Camera class, 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)
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
===================================================================
Change-Id: Ib3eab85ed97ea3e3c227617c20f8d213f17d4ba0
Transform DisplayManagerService into a SystemService and start cleaning
up other local services that it uses from window manager and input manager.
Clean up service thread initialization.
Remove unnecessary static variables from ActivityManagerService.
It's starting to become clear that we really need a better way to manage
service dependencies. Boot phases don't quite cut it.
Change-Id: If319dbd7cbfbd4812fe55ece969e818d4b20755b
With this change, setSelection will not cause java.lang.IndexOutOfBoundsException
even if a negative index is specified.
Bug: 8841916
Change-Id: Ib62a6ba235f80b7495fefb2e5cc2d5357d804310
