Status Update
Comments
kg...@gmail.com <kg...@gmail.com> #2
kg...@gmail.com <kg...@gmail.com> #3
for the "out" bundle issue, this seems indeed an issue. for the second one reported adding "debugUpdateAPKArtifact" to the path, this WAI as there can more more than one transformer and we need to automatically separate them so they do not use the same output folder. for #3, I will look at it but it might be difficult to change it at this time.
kg...@gmail.com <kg...@gmail.com> #4
xa...@android.com <xa...@android.com>
kg...@gmail.com <kg...@gmail.com> #5
Hello, this is a P1 S1 issue for a while now, and it's blocking us from upgrading to AGP 4.2 and further. What's the current status? And do you have plans to backport it to 4.2.x?
[Deleted User] <[Deleted User]> #6
no we don't have a plan to backport this. why is this blocking you from upgrading ?
yr...@google.com <yr...@google.com> #7
We sign apk's and bundles via internal service, and i don't know another way to interact with artifacts;
Yesterday i ended up with some ugly workaround:
kg...@gmail.com <kg...@gmail.com> #8
I commented on the merge request but to summarize :
you can set your signing tasks output folder to wherever you need to be :
artifacts.use(target.tasks.signedApkTaskProvider(this)).configure { signedDirProperty.set(File("/path/to/where/you/want/your/signed/files")) }
if you don't set it, then we will set a directory automatically.
ma...@gmail.com <ma...@gmail.com> #10
I checked that we do have correct behavior for FILE based artifacts like bundle :
> Task :app:debugUpdateArtifact
originalArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/intermediates/bundle/debug/signDebugBundle/app-debug.aab
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/bundle/debug/app-debug.aab
however, we still seem to not be consistent for the DIRECTORY based artifacts like APK:
> Task :app:debugUpdateAPKArtifact
Input folder: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/apk/debug
Output folder: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/intermediates/apk/debug
Input file: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/apk/debug/app-debug.apk
Alex, can you have a look ?
in...@mobileparadigm.co.uk <in...@mobileparadigm.co.uk> #11
correction, I was not correct about FILE being correct.
Instead of :
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/bundle/debug/app-debug.aab
it should be
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/app-debug.aab
``
sm...@gmail.com <sm...@gmail.com> #12
Two requests are created as they are API changes
sm...@gmail.com <sm...@gmail.com> #13
Fix will be available in Android Studio F/AGP 8.0 Canary 2 Release
Description
applicable)
Host OS: OS X
SDK tools version (available in the "About" section of the 'android' tool
UI): 23.0.2
Android Studio version: 0.8.9
STEPS TO REPRODUCE:
1. Build application requiring multiple dex files. Used example found here:
2. Observe app runs correctly on 4.x device.
3. Observe app crashes upon installation on gingerbread device.
EXPECTED RESULTS:
Multidex application runs on gingerbread device.
OBSERVED RESULTS:
Application causes dalvik crash on gingerbread devices:
E/dalvikvm( 2404): LinearAlloc exceeded capacity (8388608), last=6888
E/dalvikvm( 2404): VM aborting
F/libc ( 2404): Fatal signal 11 (SIGSEGV) at 0xdeadd00d (code=1)
...
ADDITIONAL INFORMATION:
I've seen mentions but no definitive evidence that GB devices cannot load dex files over 5Gb. As an experiment I patched dx to produce smaller dex files (see attachement). Building with the modified dx program produced an APK with smaller (no larger than 3Mb) dex files and installation errors did not occur on gb devices.
Due to this I suspect that dx needs to either by default generate smaller dex files to ensure compatibility with gb devices or be tunable in the build configuration for app producers wishing to maintain compatibility with gb.