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

Move ScanJob startup work to non-UI thread in case of state restore hang #878

Merged
merged 1 commit into from
May 29, 2019

Conversation

davidgyoung
Copy link
Member

@davidgyoung davidgyoung commented May 15, 2019

This is an attempt to fix #814.

@liloMoovel, can you please reproduce the issue with this library variant and see if it makes a difference? You will need to compile off of this branch and make a binary build:

git clone https://github.com/AltBeacon/android-beacon-library.git
git checkout fix-restore-hang-on-ui-thread
./gradlew build

The above will produce a binary aar file in lib/build/outputs/aar. You will then need to point your app's build.gradle file at that aar file instead of the version of this library in jcenter.

@lmoonow
Copy link

lmoonow commented May 16, 2019

Hi David i'm still getting the same StrictMode error. Looks like although the scan job was started on a separate thread with the fix, the onCycleEnd() callback in ScanHelper is calling updateMonitoringStatus() on the main thread.

@davidgyoung
Copy link
Member Author

davidgyoung commented May 16, 2019

@liloMoovel, you mentioned StrictMode here -- are you just using that to look for any disk access on the main thread? Or do you have some way to actually reproduce the crash from #814?

The crash from #814 was about a hang writing to storage that happened to be on the UI thread. So the idea of this PR was to try to fix that specific crash by moving that operation off of the UI thread. Moving all storage operations off the UI thread may have value, but will clearly require more effort and is beyond what is intended here.

@lmoonow
Copy link

lmoonow commented May 20, 2019

I apologize, I misundertood the issue from #814. I suspected that some devices were blocking disk access on the main thread so I used StrictMode to determine what part of the code doing this. However it appears there's a larger compatibility problem with Android 9 devices. When I set up my apps to start monitoring beacons. My Android 8 devices work perfectly. On 3 Google Pixel phones running android 9, I am getting some unstable behavior. I'm seeing false callbacks of didExitRegion() followed a didEnterRegion() repeatedly. On another device Samsung S9 running Android 9, I do not get any beacon monitoring callbacks at all but I can see the call to start monitoring. I can open a separate ticket if that works better for you.

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

Successfully merging this pull request may close these issues.

ANRs due to the ScanState.restore being called on the main thread
2 participants