| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I5620c60b5bdbdcff1e9a8ede30f1cd4552481c95
|
|
The dex number is considered invalid if it is not found in
SharedPreferences or the persisted value is less than 1. My only theory
for how this could occur is SharedPreferences corruption.
In this scenario prior to this change, MultiDex would think there were
no secondary dex files to extract and the application would crash at
runtime with ClassNotFoundException.
Bug: 62483082
Change-Id: If3671b53b06bb2fb97a9dd82858a6f43b0e1dc1c
Test: mmma -j frameworks/multidex
|
|
This saves 5-10ms on a JellyBean Samsung Nexus S for the check
to see whether the VM supports multidex natively.
On a newer Samsung S7 phone it saves 0.5 ms.
Test: manually tested on old and new devices.
Bug: 74259172
Change-Id: Ic05645deb5b4b990d07c726aa0fdd5f0cfa5884b
|
|
Robolectric at somepoint changed to return a valid Java ClassLoader from
Context.getClassLoader(), breaking the check in MultiDex.
Modify this check to ensure a valid Dex compatible classloader.
Test: Added integration tests in Robolectric; m -j checkbuild
Change-Id: I9df517e25460daa5fabfe8cba88cdc5d9bb16de2
|
|
Bug: 74397601
Test: make
Change-Id: Iddea6f92cc7796125cf4d1ba86cf9b7425daef72
|
|
DexPathList had a few changes accross Jelly Bean versions:
- dexElements was renamed pathElements and then renamed back to dexElements.
- Element constructor was changed twice.
Test: MultiDex tests several differents 4.x Android emulators and
devices.
Bug: 71989458
Change-Id: I242937a9f444d53cf6dd5b15d7933d0a9b51e162
|
|
On those versions DexPathList.makeDexElement is hiding problems by
logging (or just ignoring) IOException instead of throwing them.
This change includes in the library a version of makeDexElement simplified
to support only the case concerning the zip files for the extracted
secondary dexes.
Bug: 71989458 28832787
Test: MultiDexLegacyTestServicesTests2
Change-Id: I7532908eda8fcd123433222856752c2086a9ad3a
|
|
When an IOException occurs during installSecondaryDexes of
MultiDex.install, clear the extraction dir and make one supplementary
attempt to extract and install.
The obective is to recover from some cases of corrupted extractions or
corrupted odex files whitout requiring manual clearing of application
data.
The extraction, patching of the classloader, and recover is now done under
file lock protection to avoid clearing the cache directory while another
process would be using it. This should not cause more ANRs because
extraction was already done under file lock and dexopt which is the main
part of classloader patching is running under its own lock protection.
MultiDex.installInstrumentation isn't attempting this recover to keep
test failing in case of corruption and keep corrupted files and
hopefully allow more precise investigations. Note that adding recovering
capability to MultiDex.installInstrumentation would require changing
locking strategy.
Bug: 28832787
Test: MultiDexLegacyTestServicesTests2
Change-Id: I247918c1fbec8686ade12b37b8680539688a61a9
|
|
am: d14d4b8cbd
Change-Id: Iea5cf46d51bfee031ab6eafebf918b6aafcf0016
|
|
Allow installation of instrumentation secondary dex files. Both
the instrumentation and the instrumented application are installed (if
necessary) by MultiDex.installInstrumentation. Instrumentation
secondary dex files are extracted in the Application code cache folder
because it generally doesn't have access to its own folder.
Instrumentation preferences are saved in the Application preferences
with a prefix.
Bug: 31383194
Test: frameworks/base/core/tests/hosttests/test-apps/MultiDexLegacy*
Change-Id: I705ed87162326fd64128454aa144a359b09436cd
|
|
Bug: 36122649
Test: ./gradlew dist test connectedAndroidTest
Change-Id: I79578f683146a3ea16521cd090d113698a14c5f5
|
|
Protect extracted dex files from modifications by checking their crc and
modification time. In case of change, proceed to a new extraction.
Those checks are replacing the check of the zip integrity by
opening it with a ZipFile.
Test: SupportMultidexHostTest (from tradefed)
Bug: 32159214
Change-Id: I09aa01550782f5f550bee6fc91709455e82c1057
|
|
The check is unnecessary in MultiDex.install because it was already done
by MultiDexExtractor.load. The retry on bad extraction is also included
in MultiDexExtractor.load so it was redundant too.
Test: SupportMultidexHostTest (from tradefed)
Change-Id: I877a99db0e0c562ac47a7c5c87d7f3e1d70884e6
|
|
This is a poor protection from some attack against application that
would be made to overwrite their extracted secondary dex files.
The protection is poor because marking the dex files read only will
protect only some applications depending on their implementation.
Test: MultiDexLegacyVersionedTestApp
Bug: 32159214
Change-Id: I88c6fc72284f4e0b832dc4d840c9c636a1234638
|
|
|
|
Due to package install races it is possible for a process to be started from an
old apk even though that apk has been replaced. Querying for ApplicationInfo by
package name may return information for the new apk, leading to a runtime with
the old main dex file and new secondary dex files. This leads to various
problems like ClassNotFoundExceptions. Using context.getApplicationInfo()
should result in the process having a consistent view of the world (even if it
is of the old world). The package install races are eventually resolved and old
processes are killed.
Test: Passes Google Play services tests
Change-Id: I95257d851eb678c55a19e731183f7add2b540615
|
|
Temp files are removed unconditionally in a finally block following extraction.
However, if the process is killed during extraction this finally block will not
run. Because temp files started with extractedFilePrefix, they wouldn't be
cleaned up in prepareDexDir(). This change ensures that prepareDexDir() will
remove any existing temp files before extraction begins.
Bug: 27769642
Bug: 33718827
Test: Passes Google Play services tests
Change-Id: I803ba2c7234801551d36cbbe2941eeaa986d31f8
|
|
Bug: 30076851
Change-Id: I6a148d0038baebfcfb987bf3ca498a0acf5d106c
|
|
This prevernt multiple processes of the same application from
simultaneously caching the same secondary dex files.
Bug: 27263431
Change-Id: If78ce2d2c5a37a3299b2bb3fa598a3ddd6acb7dd
|
|
On API 19 and 20, the library was trying to save "suppressed exceptions"
in the loader.dexElementsSuppressedExceptions but the field is not
there, it's in DexPathList, so the correct path is
loader.pathList.dexElementsSuppressedExceptions.
Bug: 28808797
Change-Id: I549e2120e744345a86df2f588f03823d9dfab659
|
|
On some devices it seems impossible to read or write the application
data directory. There, creating code_cache at the proper location is
impossible. In this case fallback to the 'files' directory. This may
lead to not cleaning the useless extracted secondary dex files if one
such devices is ever updated to L.
Bug: https://code.google.com/p/android/issues/detail?id=79388
Change-Id: I4b6725572f10fd511992dc8a5043d2f135abd3a5
|
|
Use only mkdir since our usage is a simple case.
Bug: https://code.google.com/p/android/issues/detail?id=79388
Change-Id: Iab7504f3c38c660f93ab1249895be454af5ff84d
|
|
By explaining the full story in README.txt.
By inlining API 11 constants so we can really compile the library against API 4.
Change-Id: I423e807114c15805e97860ff5db22ef9ff1e24c0
|
|
This should allow an automatic cleaning when updating to L without having to
check at each launch.
Bug: 10447095
Change-Id: I3c0ecc1430ced4592f630ec4c6d8a1a2219e8141
|
|
There may be a need for clearing those unused extracted files after an OTA
bringing Art L on the device.
Bug: 10447095
Change-Id: I80b9c0afa2bd8dfa0cf04e96fb04ba2527da0fe5
|
|
It was decided that it would be the revision of multidex native support and
that it is the criterion that should be used to discriminate between VMs
capable of multidex and others.
Bug 14238145.
See bug 10447095 for discussions about the deactivation criterion.
Change-Id: I50922972d1d5b3019a111d5a1b4f2f18af9713ed
|
|
|
|
The class loader is the same in KK (API 19) & KKWT (API 20), so only
a version bump was needed.
Change-Id: Ib5112e60c9a54ed042e9c71b075ecb5302c1b717
(cherry picked from commit b420940060dbce01a861760d5830416d0e9bb802)
|
|
Change-Id: I0600b6f75005881c549150ea2e0b18800747bf73
|
|
Reduces load time if extraction was already made. It appeared that
new ZipFile was really slow because it's preparing much things as
soon as it's instanciated.
The new criteria consist of the last modified time of the apk plus
the crc of the apk's central directory, last modified time should
be enough for nearly all modifications and the crc is here to try
to handle an OTA mixing with dates.
The transition from old criteria to new should be good: since there
will be no stored values they would be detected as a new installation.
Change-Id: Id390b77b03d794b8b7feb91eb0daae1126c6d691
|
|
|
|
Multidex installation in Application.attachBaseContext()
requires only one call point to MultiDex.install() per Application
so let's provide a default multidex capable Application.
Change-Id: Icfa1993c4b3d7c5a7d1783d4ca6d5b9ea31adb8b
|
|
The bug was caused by a comparison of Long instances instead of long
values and was leading to the library always detecting that the
secondary dex files needed a fresh exctraction.
bug 12776578
Change-Id: Ia7056a130cf6e99094e4f456b086e141c1255725
|
|
The file deletion when finding that the source apk file size
was different than what was stored in SharedPreferences causes a race
condition when multiple processes are executing this code, where one
process could erase the secondary zip file while a different process had
already started to create the zip file. This check is unnecessary and
has been removed.
Also, changed the parameter for getting the SharedPreferences to
Context.MODE_MULTI_PROCESS, which forces a re-read of the key/value
pairs from the file.
This should also fix the original bug b/12550057.
Bug: 12594955
Bug: 12550057
Change-Id: I53f4bca0d03a5737d802509274520a78effcf228
|
|
This addresses an edge case where the secondary dex is not reloaded
when it should because of an OTA due to the modification time of the
PrebuiltGmsCore.apk in the system image is never different even though
PrebuiltGmsCore.apk may have changed in the OTA. This performs two
checks, the first is that the overall size of the apk is the same.
The second is to check that the number of dex files are the same, and
the CRC values of the dex file zip entries are the same.
Bug: 12550057
Change-Id: I526f6b88cfc7957840b0c35aaad0eab0cd776f7e
|
|
Bug: 11895788
Change-Id: Id4f6e5b09be809eeb29367bebe78c03e49864cbf
|
|
This CL is to be reverted when debug is done.
Change-Id: I47f2464a4b32affe2d63f874a1df3f8f24e569d5
|
|
Also, removed the file locking which had no effect.
Bug: 11895788
Change-Id: I8b520fff9496f289eba88690b3b583f9c43b932c
|
|
Change-Id: I548dd046f89d937f974cb5a925de70c7ecfad7a4
|
|
This would spin up a lot of code to compute this and is
not something we want to do in every process that GMS Core
runs in. Return zip file length to have some data about the
file.
Change-Id: Ibb22c54a6d8ef33c690fd35f2b69c427449ef5d1
|
|
Also, print out the SHA1 digest of the zip file for all
attempts at extracting the zip file.
Bug: 11895788
Change-Id: I4170c2362aa8370fd13bc7bed62f2e6eb3223768
|
|
- Remove 2 unused method arguments.
- Fix a bad copy paste of a comment.
- Remove a useless if.
Change-Id: I1b88b91e38cbe3c024207113f1c4a7bdc052e514
|
|
Bug: 11791202
Change-Id: Ib8f97f11287a59db0ec119a1d55913aa8df3ce33
|
|
This enables mockito tests to also run.
Bug: 11709435
Change-Id: I9ebc5f5441a396c12eb8cde554d69a003fa6e7ad
|
|
|
|
And use it to clean more accuratly old extracted files.
Fix bug 11232823
Change-Id: I23678ae07a8df955276ece7b8c0cdddef907992b
|
|
Fix bug 11415819
Change-Id: I1a1300f430f0db7b587e2f29c273884ef80f7fbe
|
|
Change-Id: I0571445e464ab74ffcb4e972159a2a7cf805f613
|
|
Also,
- Removed extraneous Eclipse-specific configuration files that are
unnecessary in the Android build tree
- Includes the patch to support API level 19 from
https://googleplex-android-review.git.corp.google.com/#/c/348129
- Checks for null and returns without patching the classloader when
getting the package manager or package name from the passed in Context
to MultiDex.install(...) since the Context object is probably a mock
context for testing.
- Moved the test runners to package com.android.test.runner, which seems
to be the standard place for all test runners.
Bug: 10674263
Change-Id: Idc894b360bd17db4acb50dd7daa2839ea8ea37e0
|
