Fixed
Status Update
No update yet.
Comments
cc...@google.com
[Comment deleted]
uc...@google.com
es...@google.com
Also of note is the adb error when trying to install bad APK: INSTALL_FAILED_DEXOPT
cc...@google.com
load dex files over 5Gb. -> load dex files over 5Mb.
es...@google.com
Same here! Looking forward to a solution :)
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
cc...@google.com
There is already an option in dx allowing to force generation of smaller dex files:
--set-max-idx-number=<value>
Unfortunately changing the default is not a solution since the linearAlloc limit can be reached at very different levels depending on the classes hierarchy and other criteria.
In addition for most applications, moving to multidex will only help to workaround the linearalloc limit for the installation. But the application will still crash against the same limit at execution. The only working use case where I know multidex can help with linearalloc is when the apk does not contains one application but distinct pieces running in separate process.
--set-max-idx-number=<value>
Unfortunately changing the default is not a solution since the linearAlloc limit can be reached at very different levels depending on the classes hierarchy and other criteria.
In addition for most applications, moving to multidex will only help to workaround the linearalloc limit for the installation. But the application will still crash against the same limit at execution. The only working use case where I know multidex can help with linearalloc is when the apk does not contains one application but distinct pieces running in separate process.
je...@google.com
cm...@google.com
Thanks for your quick response.
It's nice to know about that command line option. I do not see it in the output of 'dx --help', might be good to add that.
I'm not very familiar with the 'linearAlloc limit' issue outside of the context of the dexopt step. My sample app is able to run once the lower idx value is set, although I do not actually call into any of the library code that is bundled with the app. I assume it's undefined when/if the 'linearAlloc limit' will be hit in a large application on gb.
I'm a bit confused as to the platform compatibility of multidex given the 'linearAlloc limit' bug. What specific versions of Android are supported? The multidex code implies back to v4 (https://android.googlesource.com/platform/frameworks/multidex/+/master/library/src/android/support/multidex/MultiDex.java ) but it would seem that ICS is the earliest supported platform. Is this correct?
It's nice to know about that command line option. I do not see it in the output of 'dx --help', might be good to add that.
I'm not very familiar with the 'linearAlloc limit' issue outside of the context of the dexopt step. My sample app is able to run once the lower idx value is set, although I do not actually call into any of the library code that is bundled with the app. I assume it's undefined when/if the 'linearAlloc limit' will be hit in a large application on gb.
I'm a bit confused as to the platform compatibility of multidex given the 'linearAlloc limit' bug. What specific versions of Android are supported? The multidex code implies back to v4 (
cm...@google.com
cm...@google.com
The option is not documented in --help because it was designed for testing and we're not capable of documenting a reliable way to use it as a workaround of the linearalloc limit.
The linearalloc limit is reached when loading classes. At install time dexopt is loading all classes contained in the dex so it's facing the limit immediately. At execution the limit may be reached after some delay dependending of the usage you have of the packaged classes. If you face it at install time but not at execution, this means you never trigger the loading of some classes. In a real application those never loaded classes should have been shrinked away manually or by Proguard. The exception is when there are different groups of classes in the dex files used in separate process.
About multidex library supported versions I've merged recently a change to try to be clearerhttps://android-review.googlesource.com/#/c/108023/
The summary is that the library should work down to API 4 (Donut), but below ICS applications will probably be hit by the linearalloc limit
The linearalloc limit is reached when loading classes. At install time dexopt is loading all classes contained in the dex so it's facing the limit immediately. At execution the limit may be reached after some delay dependending of the usage you have of the packaged classes. If you face it at install time but not at execution, this means you never trigger the loading of some classes. In a real application those never loaded classes should have been shrinked away manually or by Proguard. The exception is when there are different groups of classes in the dex files used in separate process.
About multidex library supported versions I've merged recently a change to try to be clearer
The summary is that the library should work down to API 4 (Donut), but below ICS applications will probably be hit by the linearalloc limit
je...@gmail.com
for Android studio use:
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
cc...@google.com
I still have this issue and it's driving me nuts
cc...@google.com
lu...@google.com
Yes, the new behavior means when profileable/debuggable is enabled, the default debug signing config will be used if no other signing config is specified (see VariantDslInfoImpl:845).
yi...@google.com
It works fine when I use the new profileable DSL but not when I launch the new profiler toolbar (which sets the profilingMode flag under the hood).
The run config shows an IDE error and wouldn't let me proceed. See attached screenshot.
It might have something to do with when the flag is set (com.android.tools.idea.run.MakeBeforeRunTaskProvider), maybe there's some timing issue between signing and its check?
The run config shows an IDE error and wouldn't let me proceed. See attached screenshot.
It might have something to do with when the flag is set (com.android.tools.idea.run.MakeBeforeRunTaskProvider), maybe there's some timing issue between signing and its check?
cm...@google.com
This only takes effect when the flag is injected - the model Studio sees will still see that variant as unsigned.
I'd suggest the logic in Studio that blocks the run configuration in Studio from running needs to be updated so when the profileable flag will be injected it assumes that the build system will sign and doesn't warn or block deployment (for AGP versions that support it, of course)
cm...@google.com
Yi - are you the right person to own that part?
yi...@google.com
Per Diego, "my understanding is that we probably need to pass the ProfilerState.PROFILING_MODE to the ApkProvider so it can make the decision on whether it needs to be signed or not."
di...@google.com
This was fixed by
yi...@google.com
Thanks for the update. I just tried Dolphin Canary 7 (as well as studio-main dev build): when I tried to run the release variant, I got this error:
03/23 11:13:22: Launching 'app' on Google Pixel 4.
Installation did not succeed.
The application could not be installed: INSTALL_PARSE_FAILED_NO_CERTIFICATES
List of apks:
[0] '/Users/yiyiyang/AndroidStudioProjects/ProfilerTester/app/build/intermediates/apk/release/app-release-unsigned.apk'
APK signature verification failed.
Retry
Failed to launch an application on all devices
di...@google.com
What's the version of AGP? My understanding is that the flag will only work after a certain version?
yi...@google.com
7.3.0-alpha07, which supports profileable.
I just realized I set the profiling mode to debuggable. So I tried profileable, which seemed to work. Looking at ag/17044839, I believe the condition should be profilingMode != NONE as either PROFILEABLE or DEBUGGABLE is considered profileable.
I just realized I set the profiling mode to debuggable. So I tried profileable, which seemed to work. Looking at ag/17044839, I believe the condition should be profilingMode != NONE as either PROFILEABLE or DEBUGGABLE is considered profileable.
so...@google.com
Please do not use !=. if both modes are profileable add a method to the
enum class so that it can look like profileMode.isProfileable
On Wed, 23 Mar 2022 at 18:52, yiyiyang <buganizer-system+yiyiyang@google.com>
wrote:
enum class so that it can look like profileMode.isProfileable
On Wed, 23 Mar 2022 at 18:52, yiyiyang <buganizer-system+yiyiyang@google.com>
wrote:
yi...@google.com
ke...@gmail.com
Keyz33
Description
10:19 AM Error running 'app': The apk for your currently selected variant (app-profile.apk) is not signed. Please specify a signing configuration for this variant (profile).
This doesn't make sense to me, since I've in the past been able to run non-debuggable apps without signing, so I try and create a 'profile' variant which copies all the default settings from 'debug', but just sets debuggable -> false. Same error.
For some reason, I can edit the 'debug' build type to run debuggable, but not any other build type.
Build: 3.2 Beta 2, AI-181.5281.24.32.4860949, 201806252233, AI-181.5281.24.32.4860949, JRE 1.8.0_152-release-1136-b04x64 JetBrains s.r.o, OS Linux(amd64) v4.9.0-6-amd64 unknown, screens 2560x1600, 1920x1200Android Gradle Plugin: 3.3.0-alpha01Gradle: 4.8NDK: from local.properties: 15.0.4075724; latest from SDK: 15.0.4075724; LLDB: pinned revision 3.1 not found; latest from SDK: (package not found); CMake: from local.properties: (not specified); latest from SDK: /usr/local/google/sdk/cmake/3.6.3155560/bin/cmake -version/usr/local/google/sdk/cmake/3.6.3155560/bin/cmake: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory; from PATH: (not found); IMPORTANT: Please read