Since appBounds encodes both dimensions and positions, movement will
cause a diff change. This happens in situations where the dimensions
stay constant, such as dragging a PiP window around.
To avoid flooding the client side with configuration changes, this CL
checks whether the new configuration is equivalent to the existing
configuration with the exception of the position of the appBounds
before sending to the registered callbacks.
Change-Id: I8fbc94458fd9ed3b39494c3587f25e704ec02a7d
Fixes: 63927944
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
Test: go/wm-smoke
We are already taking care of updating AssetManagers affected by
path changes to a running app's ApplicationInfo. There is no need
to invalidate ALL AssetManagers, thereby unregistering them
from ResourcesManager and preventing configuration changes from
reaching them.
Bug: 64004601
Test: manual
Change-Id: I39311ec9b1dfd34eb7025836f75c92e0516bc36b
We added a couple of protection flags that also apply to
normal and dangerous permissions. These flags are folded
in the protection level breaking apps that directly and
compare against the protection constants. Apps that target
older than O SDK don't get protection flags folded into
the protection level.
Test: All permission tests pass
Added a new test to ensure no protection flags reported
for normal and dangerous permissions
Change-Id: I87b10a7695d8ecfa7156525d6f3d101fc0639513
bug:62755026
We added a couple of protection flags that also apply to
normal and dangerous permissions. These flags are folded
in the protection level breaking apps that directly and
compare against the protection constants. Apps that target
older than O SDK don't get protection flags folded into
the protection level.
Test: All permission tests pass
Added a new test to ensure no protection flags reproted
for normal and dangerous permissions
bug:62755026
Change-Id: I72547b0146e6b6919803e33ff64b7208c4a255ad
Record the class loader context for secondary dex loads and pass it to
dexopt during compilation.
The class loader context is passed from libcore every time a
BaseDexClassLoader is created and its recorded in the package dex usage
file.
Note that the context may be:
- unknown: if the dex file was not use after the the upgrade and its
context was not yet updated
- unsupported: if any of the class loaders from the loading context is
unsupported (only PathClassLoader and DelegateLastClassLoader are
supported).
- variable: if it changes over time, form one run to another.
In all the above cases the old compilation behavior is preserved for
now.(i.e. the dex file with be compiled with SKIP_SHARED_LIBRARY_CHECK)
Bug: 38138251
Test: runtest -x
services/tests/servicestests/src/com/android/server/pm/dex/
adb shell cmd package compile -f -m quicken ^Csecondary-dex
com.google.android.gms
Change-Id: I2486522fb811f9fc58a44b92642f43a41e7d5bac
The processes created by ActivityManagerInternal.startIsolatedProcess
were not being tracked by ActivityManager after creation (other than to
handle crashes), but they still had ProcessRecords created for them.
This meant that if a second process was started with the same name, a
WTF would be triggered due to the old ProcessRecord still existing.
To resolve this, we change the way that these special isolated processes
start up: instead of directly executing the main() of the requested
class after forking, the process first runs ActivityThread as with
ordinary processes. When the process attaches to ActivityManagerService,
it is given the name and parameters of the entry point class to execute
instead of being given an ApplicationInfo to bind. We also reinstate the
previously-disabled process start timeout, since the process is now
expected to attach as normal.
This means that ActivityManagerService can observe the process's death
via Binder as usual and clean up the ProcessRecord, as well as making
this process less of a special case. To ensure the process is still
treated as important, we set a minimum OOM adjustment of
PERSISTENT_SERVICE_ADJ (which is accurate as the system server is
depending on the process even though it does not directly bind to it as
a service), and exclude processes of this type from being killed due to
being empty isolated processes. The process will exit voluntarily after
the entry point function returns instead.
Bug: 19061358
Test: Upgrade the current WebView implementation APK and check for WTFs
Change-Id: Ide4f89d308851bb591194a8d59e6d581e9d59b50
