Include source layout file in exceptions thrown from
LayoutInflater. This makes it easier to trace failures
when using <include ...> tags.
You'll get something like
Caused by: android.view.InflateException: Binary XML file line #11 in com.myapp:layout/activity_main: Binary XML file line #6 in com.myapp:layout/overlay: Error inflating class MyView
Caused by: android.view.InflateException: Binary XML file line #6 in com.myapp:layout/overlay: Error inflating class MyView
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.myapp.MyView"...
Bug: 127425845
Test: Manual app launch that has invalid XML
Change-Id: I262fa9625dd2981eb22e493e9e4a1d2b7b75ef4b
* changes:
Check for empty arguments in setWhitelist().
Implemented a WhitelistHelper for whitelisting packages/activities for Augmented Autofill and Content Capture.
This allows for inspectors to do special handling on values known to be
resource IDs, such as converting them to a string format.
+ Add PropertyMapper#mapResourceId(String, int) and
PropertyReader#readResourceId(int, int)
+ Add RESOURCE_ID to @InspectableProperty.ValueType
+ Add code generation support in the annotation processor, and value
type inference for accessors annotated with a resource ID annotation
like @AnyRes.
Bug: 127348933
Test: atest --host view-inspector-annotation-processor-test
Change-Id: I132aea319dcddf51c553057c036ce5609e3c381a
Normally on a phone, there are a bunch of layers that can be considered color
space agnostic, for example NavigationBar and ScreenDecorOverlay*. Previously
we added a SurfaceControl API setColorSpaceAgnostic to allow a surface to tell
SurfaceFlinger it's color space agnostic, this patch adds a private flag in
window manager to allow views to set it via WindowManager.LayoutParams, window
manager will process this private flag and call setColorSpaceAgnostic when it's
changed.
BUG: 126616348
Test: Build, flash and boot. Use UIBench to check WCG behaviour
Change-Id: Iecee6528c86c390c70379bbc05b114c53d0cca48
ConfigParser is introduced to read the flags from DeviceConfig.
If the flag is missing, fallback to Settings.
Also, adds a new setting key: TEXT_CLASSIFIER_ACTION_MODEL_PARAMS
Test: atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/
Test: adb shell cmd device_config put textclassifier system_textclassifier_enabled false
adb shell dumpsys textclassification, observed that the flag is updated.
BUG: 123389900
Change-Id: Icbd26ec7ed223e40b60696d12327cb123b96c4fd
- Uses a String instead of URI for the main id.
- Uses FLAG_IS_PREFIX instead of isRecursive for UserDataRemovalRequest.
Test: m update-api
Test: atest CtsContentCaptureServiceTestCases CtsContentTestCases:LocusIdTest \
FrameworksCoreTests:android.view.contentcapture.ContentCaptureEventTest
Bug: 126945732
Change-Id: I34ae42678aa4021ea53ed66279cad4049ac2dcb3
Some layers, for example ScreenDecorOverlay*, only carry black, white or gray
with some transpanrency, these values are special as they are color space
agnostic. We don't need to do color conversion on them, instead we want to
intercept the color space before we send to hardware composer for validation.
This patch adds an API to allow this to happen, layers that can be considered
color space agnostic can call this API.
BUG: 126616348
Test: Build, flash and boot. Verify by calling in Letterbox.
Change-Id: I2e1384865bbae6c1bca5ab55962af6a4d529d81d
It would be nice if there is a common & reliable method for both outer
& internal modules to check the UID presense of the display.
Add more check in Display#hasAccess() to ask system if calling UID can
precense on the specific display, to consolidate only few special UIDs
& display flag checking.
Bug: 117347985
Test: atest ActivityManagerMultiDisplayTests
Change-Id: I2f8989598c99c0962e925c5aa65500972b4fc62b
+ Add a field target to @InspectableProperty
+ Refactor PlatformInspectableProcessor to process annotated fields and
generate InspectionCompanions that read fields.
+ Require that all inspectable getters and fields be public.
+ Make some hidden getters added to View for inspection public.
Test: atest --host view-inspector-annotation-processor-tests
Bug: 126913705
Change-Id: I0c012f42794885f17a397a2e3dd541b3aa4c2634
Prior to fe5dfca the frameCompleteCallback
was posted to the native Looper, which is
effectively a postAtFrontOfQueue. Since it
was switched to the Java-side looper, do
an explicit postAtFrontOfQueue
Fixes: 124801988
Test: speculative
Change-Id: I287c9f3917983503402dcfe3ee7d494eefae8d1f
If they were null, then the Parcelable would fail to work.
Bug: 126726802
Test: manual
Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014
Exempt-From-Owner-Approval: Trivial API annotations