Create ActivityClientRecord early in preExecute may cause
NullPointerException. If two LaunchActivityItem using the same token
and the 1st postExecute() comes after 2nd preExecute(), the
corresponding launching activity will be removed and cause 2nd
execute() get NullPointerException.
Since the only use case to get ActivityClientRecord in preExecute() is
just to use it to store the pending override config. We can directly
store the latest pending override config from preExecute() in
ActivityThread instead of creating ActivityClientRecord.
Bug: 201668069
Test: atest TransactionExecutorTests
atest ActivityThreadTest
Change-Id: If350e942254e54c9ec90bc63a6e50eb67d038183
Not sure why app overwrite the start intent to null, but we should
prevent app from crash in frameworks.
Bug: 210930049
Test: run test app; presubmit
Change-Id: Ifa27c2258b1e7a2a49b1a4155bd5ada79fa2d1af
As we evolve broadcasts over time, it's desirable to adjust how
they're delivered to legacy apps. Using target SDK checks is one
way to implement this, but it's not very flexible as large
developers adjust to new beta releases. Instead, the platform
best-practices are to use CompatChanges which can easily be
enabled/disabled on a per-app basis to aid debugging and triage.
Thus this change brings CompatChanges-based filtering to
BroadcastOptions, along with tests to verify it's behavior.
Bug: 209888056
Test: atest CtsAppTestCases:BroadcastOptionsTest
Change-Id: Id922d935db54e43ec37783cca612f09049999fab
Adding logging so that we can log wtfs and know where they are coming
from without the trace being swallowed by the binder. This will help
track down locations where receivers are being registered for non-system
broadcasts but aren't specifying the necessary flags.
Bug: 161145287
Bug: 207378016
Test: Just adding logging that will be deleted
Change-Id: Ib20c4015caf76ae946bbf2a7fc434777856c18fe
This is important in cases where we want to add/clear overrides for
multiple apps at the same time, without having to make a binder call for
each package and have the compat config save the changes to file and
invalidate the cache each time.
Bug: 199730202
Test: atest FrameworksServicesTests:CompatConfigTest
Test: atest FrameworksServicesTests:PlatformCompatTest
Change-Id: I3b4a3d9db12fdf99eb78c486bdd8e248fff92e50
Test: Make sure apps with custom animations set using WindowAnimationStyle actually use the custom animation when shell is enabled
Bug: 206960607
Change-Id: I1d982870837d67c74f76dd0a90aa5260d9441aba
Unless we are looking at stack traces (e.g. from strict mode) it's not
possible to identify which type of object is not being closed (most
methods are 'close' or 'release). Change the logged text to clarify.
Change-Id: Ib90eac716f43c2c2caf8d8c6fb64a7bd90562da9
Test: manual
Make the transport AIDL async and introduce a callback AIDL for passing
back results. A follow-up CL will implement the client-side portion of
the callback class and update BackupTransportClient to use it.
Bug: 202716271
Test: m -j
Change-Id: I79cb376bd2a805bf2739470a3f538207ae6bd9a0
Changes:
- Listens to changes from the client coming through IActivityClientController#requestCompatCameraControl to ActivityRecord#updateCameraCompatState
- ActivityRecord#updateCameraCompatState sends updated state via TaskInfo to WM Shell
- ITaskOrganizerController#updateCameraCompatControlState to dispatch the user interactions with the control from WM Shell triggers callback to ActivityRecord#updateCameraCompatStateFromUser
- ActivityRecord#updateCameraCompatStateFromUser remembers the user's choice and asks client to apply treatment through ICompatCameraControlCallback
Feature is guarded with config_isCameraCompatControlForStretchedIssuesEnabled
Test: atest WMShellUnitTests:ShellTaskOrganizerTests, atest WmTests:ActivityRecordTests
Bug: 206602997
Change-Id: I083aa6718bd67456bedd9444e9b78740c041f870
This is a short-term workaround to dump error log instead of throwing
the exception to unblock the test.
Bug: 209744518
Test: build pass
Change-Id: I2ece3b9d85edc1ae43038e6f69b35f59b160a3dd
(cherry picked from commit f8fc1326f7)
Because Objects.hash(Object... values) will always create an array
to wrap the "..." arguments, with additional auto-boxing for all
primitive type arguments.
This can reduce the execution time of ChangeIdStateQuery#hashCode()
by 8 times, which is usually the main cost of
CompatChanges#isChangeEnabled.
Bug: 208449209
Test: atest android.app.compat.CompatChangesTest
Change-Id: I863aa1d35e7448b5a965368272198c4529253ae0
The initial selection toolbar related architecture. Render service
part and the implementation will be revised in the follow up changes.
Bug: 190030331
Bug: 205822301
Test: manual. Can boot to home and get manager successfully.
Ignore-AOSP-First: new file for T
Change-Id: Iab5d5f2e5e48e6258a63fb0c479194c958ea61e8
Migrate the following unsafe parcel APIs in framework-minus-apex:
* Parcel.readSerializable()
* Parcel.readArrayList()
* Parcel.readList()
* Parcel.readParcelable()
* Parcel.readParcelableList()
* Parcel.readSparseArray()
This CL was generated by applying lint fixes that infer the expected
type from the caller code and provide that as the type parameter
(ag/16365240).
A few observations:
* In some classes we couldn't migrate because the class also belonged to
another build module whose min SDK wasn't current (as is the case for
framework-minus-apex), hence I suppressed the lint check
(since I'll eventually submit the lint check to the tree).
* In some cases, I needed to do the cast in
https://stackoverflow.com/a/1080525/5765705 to make the compiler happy
since there isn't another way of providing a class of type
Class<MyClassWithGenerics<T>>.
* In the readSerializable() case, the new API also requires the class
loader, that was inferred to by InferredClass.class.getClassLoader().
* Note that automatic formatting and import rely on running hooked up
to the IDE, which wasn't the case here.
Bug: 195622897
Test: TH passes
Change-Id: I11a27b9bdab7959ee86e90aa1e1cbebd7aaf883c
* changes:
Support per-process Application class (AM and client side)
Support per-process Application class (package parser)
Support per-process Application class in <process> tag
Also started using it for DPM#provisionFullyManagedDevice and
DPM#createAndProvisionManagedProfile
Bug: 188410712
Bug: 206083853
Test: atest android.devicepolicy.cts.DevicePolicyManagerTest
Change-Id: Ic5bdb2bec16c83671a7e2cc955522b2d8c82ea70
Now the <process> tag supports `android:name`, which takes a custom
Application class name. If omitted, the system defaults to the
class set in the <application> tag, or the default class which is
`android.app.Application`.
Bug: 197264681
Test: atest CtsProcessTest
Change-Id: I0650a4a7c75dc37c00875e4f0ac53656f1cbeac9
