Fixed
Status Update
No update yet.
Comments
d....@gmail.com
[Comment deleted]
an...@gmail.com
Also of note is the adb error when trying to install bad APK: INSTALL_FAILED_DEXOPT
am...@google.com
load dex files over 5Gb. -> load dex files over 5Mb.
d....@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
d....@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.
am...@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 (
d....@gmail.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
do...@gmail.com
for Android studio use:
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
gi...@gmail.com
I still have this issue and it's driving me nuts
[Deleted User] <[Deleted User]>
Thank you #4, you helped me work around this bug! This bug is indeed still there even in 25.3.1
[Deleted User] <[Deleted User]>
This bug is still there in 25.4.0 and 26.0.1. Might need to revert to 25.3.1
[Deleted User] <[Deleted User]>
This is an app-breaking issue, still present in 26.0.1.
Using the latest 26 API you might find the following activity-level fix helpful, put it in Activity onCreate:
getSupportFragmentManager().registerFragmentLifecycleCallbacks(fixFragmentLifecycleCallbacks, true);
Put this in your activity:
private final FragmentManager.FragmentLifecycleCallbacks fixFragmentLifecycleCallbacks = new FragmentManager.FragmentLifecycleCallbacks() {
@Override
public void onFragmentStopped(FragmentManager fm, Fragment f) {
ViewGroup vg = getParentContainer(f);
if (vg != null) {
//https://issuetracker.google.com/issues/37130477
// Workaround as this is not fixed as of 26.0.1. The previous working version was 25.3.1.
// To reproduce this issue, find any fragment transaction with an animation that takes time.
// As soon as the fragment transaction starts, quickly press the recent tasks button
// to minimise the app. See that when you return there is a "Ghost fragment" and the
// view is now unusable.
vg.clearDisappearingChildren();
}
}
@Nullable
private ViewGroup getParentContainer(Fragment f) {
View fv = f.getView();
if (fv != null) {
ViewParent vp = fv.getParent();
if (vp instanceof ViewGroup) {
return (ViewGroup) vp;
}
}
return null;
}
};
Using the latest 26 API you might find the following activity-level fix helpful, put it in Activity onCreate:
getSupportFragmentManager().registerFragmentLifecycleCallbacks(fixFragmentLifecycleCallbacks, true);
Put this in your activity:
private final FragmentManager.FragmentLifecycleCallbacks fixFragmentLifecycleCallbacks = new FragmentManager.FragmentLifecycleCallbacks() {
@Override
public void onFragmentStopped(FragmentManager fm, Fragment f) {
ViewGroup vg = getParentContainer(f);
if (vg != null) {
//
// Workaround as this is not fixed as of 26.0.1. The previous working version was 25.3.1.
// To reproduce this issue, find any fragment transaction with an animation that takes time.
// As soon as the fragment transaction starts, quickly press the recent tasks button
// to minimise the app. See that when you return there is a "Ghost fragment" and the
// view is now unusable.
vg.clearDisappearingChildren();
}
}
@Nullable
private ViewGroup getParentContainer(Fragment f) {
View fv = f.getView();
if (fv != null) {
ViewParent vp = fv.getParent();
if (vp instanceof ViewGroup) {
return (ViewGroup) vp;
}
}
return null;
}
};
[Deleted User] <[Deleted User]>
You can of course register the above generically app-wide, using Application.ActivityLifecycleCallbacks, and the onActivityCreated callback it gives you:
In your application:
app.registerActivityLifecycleCallbacks(lifecycleCallbacks);
Elsewhere in your application:
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks = new Application.ActivityLifecycleCallbacks() {
@Override
public void onActivityCreated(Activity activity, Bundle bundle) {
// Note that AppCompatActivity extends FragmentActivity
if (activity instanceof FragmentActivity) {
FragmentActivity supportActivity = (FragmentActivity) activity;
FragmentManager fm = supportActivity.getSupportFragmentManager();
fm.registerFragmentLifecycleCallbacks(fixFragmentLifecycleCallbacks, true);
}
}
...
};
In your application:
app.registerActivityLifecycleCallbacks(lifecycleCallbacks);
Elsewhere in your application:
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks = new Application.ActivityLifecycleCallbacks() {
@Override
public void onActivityCreated(Activity activity, Bundle bundle) {
// Note that AppCompatActivity extends FragmentActivity
if (activity instanceof FragmentActivity) {
FragmentActivity supportActivity = (FragmentActivity) activity;
FragmentManager fm = supportActivity.getSupportFragmentManager();
fm.registerFragmentLifecycleCallbacks(fixFragmentLifecycleCallbacks, true);
}
}
...
};
Description
Version used: 25.1.0
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: every devices I tested on, for example : Sony Xperia Z3 tablet, Samsung Galaxy Tab S2.
It seems related to other issues being reported about fragment replace transactions, but this one does not use the replace method.
Steps to reproduce :
- Add a fragment with a simple transaction :
getSupportFragmentManager()
.beginTransaction()
.setCustomAnimations(android.R.anim.fade_in, android.R.anim.fade_out)
.add(R.id.fragment_container, new TestFragment())
.commit()
- Remove the fragment using a simple remove, and just after start a new activity :
final Fragment fragment = getSupportFragmentManager().findFragmentById(R.id.fragment_container);
if (fragment != null) {
getSupportFragmentManager()
.beginTransaction()
.setCustomAnimations(android.R.anim.fade_in, android.R.anim.fade_out)
.remove(fragment)
.commit();
startActivity(new Intent(this, MainActivity.class));
}
- Go back to the old activity
What should happen : the fragment that was added should not be here anymore.
What happens : the fragment is still here. But the thing is it's only some sort of "ghost view" : it's impossible to reach it in debug using the view hierarchy. I even tried to activate the debug option "show layout bounds", which does not shows the bound on the fragment view. The view is not clickable, if I call removeAllViews() on the container it's still here.
Another thing : even with this view still here, if I re-add a fragment it will be added below the "ghost view". Everything works, but the old view is still here.
I attached a sample project to reproduce this issue. The "remove fragment" button is just here to validate the behaviour without starting another activity. You can see the bug using :
- "Add fragment"
- "Remove fragment and start activity"
- Press the back button
The old fragment is still here. If you press the add fragment button, another fragment will appear behing the old fragment, which should not be possible.
If you use the "show layout bounds" option, the bug is really visible :
- Start from scratch (kill the app)
- "Add fragment"
- Enable the "show layout bounds" option.
- "Remove fragment and start activity"
- Press the back button
Here everything seems normal except for the fragment still being here. But if you disable the "show layout bounds" option, the fragment view will stay unchanged, with layout bounds displayed. As if it were a cached view not recognized by the system.
I also attached a screenshot of this behavior. You can see the "show layout bounds" option is disabled, but it still shows on the fragment view.
All this does not happen with support lib 25.0.1.