Age | Commit message (Collapse) | Author |
|
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
|
|
am: edc9c8d3e1
Change-Id: Id8bc64c0537bae7915cb416963ea695484cd4859
|
|
Orignally the Make version doesn't build them for unbundled branches.
So turn off the build for these targets in Android.bp.
Test: N/A
Bug: b/70351683
Change-Id: Ia8924ad258254f7b23edfb792a11e4af7b6089ce
|
|
am: 2121bfabfe
Change-Id: I86adfaf656a3cc050b7ff688efe36ee95c998b28
|
|
Bug: b/70351683
Test: m -j offline-sdk-docs
Change-Id: I59951b48511c55285a5123d2fc397f9a5a8b2d8b
|
|
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
|
|
Test: ./gradlew dist
Change-Id: Iae1567d72cfde7d4d52f62f0a121e239bb002566
|
|
Source code requires Java 7 source level.
Test: ./gradlew dist
Change-Id: I8acef77485d961850d529692b61210784204d1a0
|
|
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: 78a8310ade
Change-Id: I1d857f3d2d6291b7ad207085673bdc99578047d8
|
|
ba450e759c
am: 4f494eea21
Change-Id: Ibf6df76b1a35af6577ca95c982799a1282b9128a
|
|
am: d14d4b8cbd
Change-Id: Iea5cf46d51bfee031ab6eafebf918b6aafcf0016
|
|
am: ba450e759c
Change-Id: Ie98460078d6b1ae8ff3803ced18c7563214fee05
|
|
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
|
|
They must be in main dex or InstrumentationTestRunner won't find them.
Bug: 31383194
Test: frameworks/base/core/tests/hosttests/test-apps/MultiDex*
Change-Id: I76ea9e9f46fa95f6a1f2d35410480be42f7a5151
|
|
These is a conflict when using this meta tag together with Android Support
Library as it specifies a different version.
Bug: 38037855
Test: ./gradlew dist
Change-Id: If23423bcbf93a4cd4a0b5e3a5593d1f563756933
|
|
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
|
|
- Stop collecting build id and version to allow better behavior with
incremental builds.
- Make it resistant to git errors.
Test: mm
Change-Id: I03b1e36048f92f50227cfc0e370454438bee31cf
|
|
Test: mm
Change-Id: I70c50b5b9fe7f06b0adde5616590aec24b6d0dff
|
|
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
|
|
* commit 'f9f54ac65185338b2726a9c6b9d791c5994c38e2':
Use Context.getFilesDir as a backup dex location
|
|
* commit '606af94785cb96d418d87fe5a90bb2e09ccfa97f':
Use Context.getFilesDir as a backup dex location
|
|
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
|
|
(cherry picked from commit 805db15e4d7baa57062ad08fb03eeac8691475c8)
Change-Id: I4cae9fa3ba272690461c29bf8d9779350b99ae52
|
|
Change-Id: I807ab1791b1704b5b2ec48c608ac474e0d2b7850
|
|
* commit '8c2abf7f471b061b737e700af711e9d5d6883b40':
Workaround mkdirs concurency problems
|
|
Use only mkdir since our usage is a simple case.
Bug: https://code.google.com/p/android/issues/detail?id=79388
Change-Id: Iab7504f3c38c660f93ab1249895be454af5ff84d
|
|
This is mostly a copy of the support libs' gradle files,
in order to generate a support library that will contain
the current public versions + the new version being built.
Change-Id: I4937073909206653bd0ffd128694161cf59445a9
|
|
To allow automatic configuration when using Jill/Jack.
This is a temporary change untill Jack and Jill are fully
integrated into the SDK build tools.
(cherry picked from commit f50beca07827921e005ce6825bbc874a843f91e1)
Bug: 18112662
Change-Id: I8b9292b05c90d790edade62ac682dba35e7d3e96
|
|
To help compilation with jack of applications using a multidex library.
(cherry picked from commit 2921acf84ac6114a6e600b7ab0237d835ef9e43f)
Bug: 18112662
Change-Id: I0f7535ba859859ec30fc6a07447f1075e7b4deb0
|
|
By explaining the full story in README.txt.
By inlining API 11 constants so we can really compile the library against API 4.
(cherry picked from commit e99daea7a3aec5ffac13b4283685e8d2a5994ad9)
Bug: 18112662
Change-Id: I03a4d5f773bebbe09fcde04a340bdf8abfdbc068
|
|
The version data is kept in a small resource file.
(cherry picked from commit 6d70d23facddf0e780cfb08a7f9af94da510bf96)
Bug: 18112662
Change-Id: I174145a4e93463b0106d45ae86e6dba1be8715e8
|
|
To allow automatic configuration when using Jill/Jack.
This is a temporary change untill Jack and Jill are fully
integrated into the SDK build tools.
Change-Id: I4ee88cb0191211d79f71f305ac7a42e357ec63c2
|
|
To help compilation with jack of applications using a multidex library.
Change-Id: I6502212b9e0a04360d74d88db933f9b58eff974d
|
|
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
|
|
The version data is kept in a small resource file.
Change-Id: I3de1a28fee68726121f3738791439bc315623ed7
|
|
This should allow an automatic cleaning when updating to L without having to
check at each launch.
Bug: 10447095
(cherry picked from commit 590a07e63868f0a1da311ff22b4a9f35eb48a865)
Change-Id: I90b80c0c196b5da2b63bced30b2ba5e93ecb594a
|
|
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
|
|
|