Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
[Comment deleted]
il...@google.com
lo...@gmail.com
[Comment deleted]
ja...@gmail.com
Also of note is the adb error when trying to install bad APK: INSTALL_FAILED_DEXOPT
b9...@gmail.com
load dex files over 5Gb. -> load dex files over 5Mb.
ka...@gmail.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
b9...@gmail.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.
yc...@gmail.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 (
il...@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
[Deleted User] <[Deleted User]>
for Android studio use:
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
kk...@google.com
I still have this issue and it's driving me nuts
il...@google.com
Re #13 - The original issue as demonstrated by the sample projects attached has been fixed in 27.1.1.
You could certainly have an issue with similar symptoms but with a different root cause - if you're able to reproduce an issue even with the latest 28.0.0-alpha3, please file a new bug with a sample project that reproduces your issue.
You could certainly have an issue with similar symptoms but with a different root cause - if you're able to reproduce an issue even with the latest 28.0.0-alpha3, please file a new bug with a sample project that reproduces your issue.
al...@gmail.com
The following scenario is still unfixed:
Have Don't keep activities enabled.
Start the app.
Push home button.
On 27.0.2 I have the following output at logcat:
V/ViewModelFirst: Created
V/ViewModelFirst: onCleared
V/FragmentFirst: onDestroy
V/MainActivity: onDestroy
Which totally correct.
But on 27.1.1 till 28.0.0-alpha3 I have the following output at logcat:
V/ViewModelFirst: Created
V/FragmentFirst: onDestroy
V/MainActivity: onDestroy
As we can see activity and fragment was destroyed but viewModel was not notified with onCleared.
I suspect that in case if the Don't keep activities will be disabled and the app at background will be naturally unloaded by Android at some moment of time the viewModel.onCleared() will not be called which is very sad.
Have Don't keep activities enabled.
Start the app.
Push home button.
On 27.0.2 I have the following output at logcat:
V/ViewModelFirst: Created
V/ViewModelFirst: onCleared
V/FragmentFirst: onDestroy
V/MainActivity: onDestroy
Which totally correct.
But on 27.1.1 till 28.0.0-alpha3 I have the following output at logcat:
V/ViewModelFirst: Created
V/FragmentFirst: onDestroy
V/MainActivity: onDestroy
As we can see activity and fragment was destroyed but viewModel was not notified with onCleared.
I suspect that in case if the Don't keep activities will be disabled and the app at background will be naturally unloaded by Android at some moment of time the viewModel.onCleared() will not be called which is very sad.
lb...@gmail.com
@15 You should open a new thread. Once Google closes an issue , there is a much smaller chance they ever read what you've written in it, and it happens a lot, sadly
al...@gmail.com
3g...@gmail.com
file sdcard encrypt....
[Deleted User] <[Deleted User]>
Common
Description
implementation 'com.android.support:appcompat-v7:27.1.0'
implementation "android.arch.lifecycle:runtime:1.1.0"
implementation "android.arch.lifecycle:extensions:1.1.0"
implementation "android.arch.lifecycle:common-java8:1.1.0"
Version used: 27.1.0
Theme used: N/A
Devices/Android versions reproduced on: Emulator 24
- Relevant code to trigger the issue.
Make an Activity that contains a Fragment.
Make the Activity use a ViewModel, and make the Fragment also use a ViewModel.
Start the Activity and press back.
The Activity's ViewModel's onCleared method is called.
With AppCompat 27.0.2, the Fragment's ViewModel's onCleared method is called (as it should)
With AppCompat 27.1.0, the Fragment's ViewModel's onCleared method is not called (incorrect).
See the attached project that shows the issue.
With 27.0.2, the logs read:
---------------------------
org.jraf.android.viewmodelproblem.MainActivity: onCreate
org.jraf.android.viewmodelproblem.MainActivityViewModel: constructor
org.jraf.android.viewmodelproblem.MainFragment: onCreate
org.jraf.android.viewmodelproblem.MainFragmentViewModel: constructor
[back is pressed]
org.jraf.android.viewmodelproblem.MainActivity: onDestroy
org.jraf.android.viewmodelproblem.MainActivityViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragmentViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragment: onDestroy
With 27.1.0, the logs read:
---------------------------
org.jraf.android.viewmodelproblem.MainActivity: onCreate
org.jraf.android.viewmodelproblem.MainActivityViewModel: constructor
org.jraf.android.viewmodelproblem.MainFragment: onCreate
org.jraf.android.viewmodelproblem.MainFragmentViewModel: constructor
[back is pressed]
org.jraf.android.viewmodelproblem.MainActivity: onDestroy
org.jraf.android.viewmodelproblem.MainActivityViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragment: onDestroy
This seems to happen because of line 1645 of Fragment, this test:
if (mViewModelStore != null && !mHost.mFragmentManager.isStateSaved()) {
is always false because mHost.mFragmentManager.isStateSaved() is true.