| cdbae800b4a665572ef3105d4187082a8586c49e |
|
11-Sep-2017 |
Shubham Ajmera <shubhamajmera@google.com> |
Merge "Handle '&' in DexoptUtils#encodeClassLoader"
|
| 557c054935c0864b42ce49541d12d32ae6a797bc |
|
05-Sep-2017 |
Shubham Ajmera <shubhamajmera@google.com> |
Handle '&' in DexoptUtils#encodeClassLoader
For system apps, we pass '&' for CLC.
The method was treating this as a path as a result we were getting
wrong encoding for CLC.
This was causing dexopt failures for A/B OTA.
Removed the secondary dex file dexopt till we fixed it.
Bug: 65067046
Test: runtest.py -x \
frameworks/base/services/tests/servicestests/src/com/android/server/pm/dex/DexoptUtilsTest.java
Change-Id: I9aa440750c811676c86d8c6d0d451077d0edf5a0
/frameworks/base/services/core/java/com/android/server/pm/dex/DexoptUtils.java
|
| da09815e2cd3d3968c66a8d52e620ee07d8204dd |
|
02-Sep-2017 |
Calin Juravle <calin@google.com> |
Handle configuration splits when creating the class loader context
Configuration splits have no dependencies which can lead to exceptions
when computing their class loader context.
In general, we do not need to compute the class loader context for apks
without code.
This CL addresses the issue by ignoring "code" paths with no actual code.
Bug: 65159159
Test: adb install-multiple config_splits
runtest -x
services/tests/servicestests/src/com/android/server/pm/dex/DexoptUtilsTest.java
Change-Id: Ida1eb901eecba4a4266de73022f6ee4659367873
/frameworks/base/services/core/java/com/android/server/pm/dex/DexoptUtils.java
|
| f1ff36f0f99ebb41d0c7e0f3248506a56998fa3f |
|
22-Jul-2017 |
Calin Juravle <calin@google.com> |
Use the class loader context when optimizing secondary dex files
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
(cherry picked from commit 3bec94d78b0a66c4fa5cebd851ea33bcc51916b0)
Change-Id: Ie8b78c7c0d5de43733b3d116f8dcb3a65324cca8
/frameworks/base/services/core/java/com/android/server/pm/dex/DexoptUtils.java
|
| 3bec94d78b0a66c4fa5cebd851ea33bcc51916b0 |
|
22-Jul-2017 |
Calin Juravle <calin@google.com> |
Use the class loader context when optimizing secondary dex files
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
/frameworks/base/services/core/java/com/android/server/pm/dex/DexoptUtils.java
|
| 305aeea38f96f0b94ad4be5cb979dd9cf98cf7df |
|
15-Jul-2017 |
Calin Juravle <calin@google.com> |
Fix splits class loader context for non dependant splits
If the app doesn't request for splits to be loaded in isolation or does
not declare inter-split dependencies, then all the splits are loaded in
the base apk class loader (in the order of they are defined).
Fix the class loader context passed to dex2oat to reflect the runtime
loading logic.
Bug: 38138251
Test: runtest -x
services/tests/servicestests/src/com/android/server/pm/dex/DexoptUtilsTest.java
Change-Id: Ia0623d38883ae244fd16c0afb053fef016bf260a
/frameworks/base/services/core/java/com/android/server/pm/dex/DexoptUtils.java
|
| 19da1cf72e8c448743a8c27ac6d73424ae42c7ec |
|
13-Jul-2017 |
Calin Juravle <calin@google.com> |
Encode the entire class loader context for dex2oat
Until now the split dependencies were passed as a flatten list to dex2oat.
In the presence of DelegateLastClassLoaders this is no longer enough to
ensure the correctness of the compilation.
This CL encodes the split dependencies together with their declared class
loader in a format accepted by dex2oat.
Bug: 38138251
Test: runtest -x
services/tests/servicestests/src/com/android/server/pm/dex/DexoptUtilsTest.java
Change-Id: Iaabd5d8bd5e6d027a8de5a408777fd517063d9f1
/frameworks/base/services/core/java/com/android/server/pm/dex/DexoptUtils.java
|