Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when activity re-created with set background process limit as 0 #518

Closed
bugbunney opened this issue Jul 1, 2015 · 3 comments
Closed

Comments

@bugbunney
Copy link

How to set background process as 0
http://www.tomsguide.com/faq/id-2316489/limit-background-process-android-device.html

A fragment in activity and execute below.

ImageView imageView=(ImageView)getView().findViewById(view, R.id.attachment);
Glide.with(activity).load(url).asBitmap().into(imageView);

It's everything well. The image view display picture correctly.

But I press home key to exit app and next step enter the other app and exit after launched.

At latest, I return to my app and crash right now.

I try modify

Glide.with(activity).load(url).asBitmap().into(imageView);

to

Glide.with(fragment).load(url).asBitmap().into(imageView);

It still crash again.

I comment

//Glide.with(activity).load(url).asBitmap().into(imageView);

and run the above flow. It is everything well.

My device is LG G3 Android 5.0.1

It display msg about

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.xxx.app/com.xxx.app.child.activity.SendMessageActivity}: android.view.InflateException: Binary XML file line #2: Error inflating class fragment
   at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2305)
   at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2365)
   at android.app.ActivityThread.access$800(ActivityThread.java:148)
   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1283)
   at android.os.Handler.dispatchMessage(Handler.java:102)
   at android.os.Looper.loop(Looper.java:135)
   at android.app.ActivityThread.main(ActivityThread.java:5272)
   at java.lang.reflect.Method.invoke(Native Method)
   at java.lang.reflect.Method.invoke(Method.java:372)
   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:909)
   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:704)
Caused by: android.view.InflateException: Binary XML file line #2: Error inflating class fragment
   at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:763)
   at android.view.LayoutInflater.inflate(LayoutInflater.java:482)
   at android.view.LayoutInflater.inflate(LayoutInflater.java:414)
   at android.view.LayoutInflater.inflate(LayoutInflater.java:365)
   at android.support.v7.app.AppCompatDelegateImplV7.setContentView(AppCompatDelegateImplV7.java:249)
   at android.support.v7.app.AppCompatActivity.setContentView(AppCompatActivity.java:106)
   at com.oshare.app.core.ChildActionBarActivity.onCreate(ChildActionBarActivity.java:13)
   at android.app.Activity.performCreate(Activity.java:5977)
   at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1105)
   at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2258)
   ... 10 more
Caused by: java.lang.IllegalStateException: Fragment com.oshare.fragment.message.SendMessageFragment did not create a view.
   at android.support.v4.app.FragmentManagerImpl.onCreateView(FragmentManager.java:2200)
   at android.support.v4.app.FragmentActivity.onCreateView(FragmentActivity.java:300)
   at android.support.v7.app.AppCompatDelegateImplV7.callActivityOnCreateView(AppCompatDelegateImplV7.java:838)
   at android.support.v7.app.AppCompatDelegateImplV11.callActivityOnCreateView(AppCompatDelegateImplV11.java:34)
   at android.support.v7.app.AppCompatDelegateImplV7.onCreateView(AppCompatDelegateImplV7.java:826)
   at android.support.v4.view.LayoutInflaterCompatHC$FactoryWrapperHC.onCreateView(LayoutInflaterCompatHC.java:44)
   at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:725)
   ... 19 more
@bugbunney bugbunney changed the title Crash when app recreated with set background limit as 0 Crash when app re-created with set background limit as 0 Jul 1, 2015
@bugbunney bugbunney changed the title Crash when app re-created with set background limit as 0 Crash when activity re-created with set background limit as 0 Jul 1, 2015
@bugbunney bugbunney changed the title Crash when activity re-created with set background limit as 0 Crash when activity re-created with set background process limit as 0 Jul 1, 2015
@TWiStErRob
Copy link
Collaborator

A few questions / investigation tips:

  1. Could you please create a mini app where this issue can be reproduced? (Make a copy of the app and strip all app-related logic while it still reproduces).
  2. How is the fragment created in the activity? (from stack it looks like it's in xml via <fragment)
  3. When is the Glide call made? (in fragment lifecycle) What happens if you move it to onViewCreated?
  4. Did you check if your fragment returns a non-null view from onCreateView? I don't see how Glide can affect that. Try to Log.wtf("FRAGMENT", String.valueOf(view)); return view;
  5. Try with the "Don't keep activitiies" option on and background limit set to normal, I suspect the same thing should happen, even if you don't start the other app.
  6. Try Glide.with(activity.getApplicationContext()), it's not a solution, but a big hack that may prevent this from happening.

@bugbunney
Copy link
Author

My sample code
https://github.com/bugbunney/GlideTest

About above suggestions
1~5 are still crash with set background process as 0.
And sometimes it still crash when reenter app but I never call Glide do anything.
About 5 ,it maybe crash that according to device resources usage.

Suggestion 6 is fine.It will not crash when reenter app after exit from background.
I guess that the activity maybe an instance but not ready.

@TWiStErRob
Copy link
Collaborator

Thank you very much for the sample app!

The appcontext hack works, because it prevents Glide from registering it's own "listeners" around the activity and fragment: Glide normally adds a UI-less fragment to the FragmentManager of what you use in with() to receive lifecycle notifications, obviously the Application doesn't have one.

Root cause

I debugged the app, and checked why the appcompat fragment manager thinks there's no view created. The problem is that your static fragment doesn't have any identification, so it falls back to looking for containerId=0. Since the Glide fragment doesn't have ID (actually it has a tag, but for some reason that's not enough) it does the same and the fragment manager finds the Glide fragment for containerId=0 instead of yours.

Workaround

I managed to make it work by adding an android:tag or android:id to your static fragment in xml, and actually if you look closely there's a lint warning saying exactly that:
image
The last line is also important here, because it falls back to container ID, which is again non-existent for both Glide and your fragment, and then they both fall back to 0 → conflict.

Fix (most likely wontfix)

To be honest, this looks like an appcompat bug to me, which probably happens extremely sparingly. I think a whole lot of things have to match. That defaulting int containerId = parent != null ? parent.getId() : 0; looks suspicious to me. I think that 0 should be View.NO_ID.
We can't work around this issue from Glide, becuase we would need a proper View ID, but there are no resources in Glide, and there are no plans to include them to keep it a simple jar. I really think most fragments are created dynamically or have identification to be able to do state transitions (anim, show, hide) on them and that's why it didn't come up before.

So in the end "with set background limit as 0" doesn't really have to do with the bug, it just makes things happen faster, actually the whole time I was testing with "Do not keep activities". The result is the same, the activity is always destroyed when it's paused.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants