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

Android: Bump Target SDK to 28 #1178

Open
dosiecki opened this issue Mar 15, 2019 · 14 comments

Comments

Projects
None yet
3 participants
@dosiecki
Copy link
Collaborator

commented Mar 15, 2019

Per (https://android-developers.googleblog.com/2019/02/expanding-target-api-level-requirements.html), GOOG's draconian rules about target API versions have once again been bumped. The effort started in our 9.0_b1 alpha will need to be expanded to go up another few versions so we can actually push updates to production.

@samuelclay

This comment has been minimized.

Copy link
Owner

commented Mar 24, 2019

Hey, sorry I sent an email to you before seeing this ticket. Is there any way to prioritize this work for deployment this week or next?

@dosiecki

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 14, 2019

As expected, bumping the target APIs to a version high enough that GOOG will accept our update for publication has broken quite a few things. Mainly, since the newer APIs now prohibit the old style Service-based background sync we were using, we have to use the new JobService based background worker that I pushed up to master in a09e1e7. However, as anyone who has built and used that code might notice, some of our hooks into launching the service in the forground trigger some incredibly bad UI lag on some devices. I'm working to re-wire invocation to something we can fully control, but there are more than a few touch points required.

@caleb-allen

This comment has been minimized.

Copy link
Contributor

commented May 7, 2019

As suggested, I'm picking this up where it was left off, and bringing the target to 28. Also looking into the UI lag to nail down what's going on.

@caleb-allen

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

@dosiecki do you have any test cases that produce the UI lag you mentioned?

@samuelclay

This comment has been minimized.

Copy link
Owner

commented May 8, 2019

There's a test account called android_speed that you can login to. I believe the password is newsblur.

@samuelclay

This comment has been minimized.

Copy link
Owner

commented May 8, 2019

Oh, what's your username? I'll mark you as staff so you can login as any user necessary.

@dosiecki

This comment has been minimized.

Copy link
Collaborator Author

commented May 9, 2019

@caleb-allen

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

Oh, what's your username? I'll mark you as staff so you can login as any user necessary.

@samuelclay it is caleballen

@dosiecki thanks! Much appreciated

@caleb-allen

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

I've done a good amount of profiling, here's what I've got.

I'm not able to recreate any huge amount of lag on my Pixel XL on Q or the emulator, aside from a few dropped frames right around the redraw after the results arrive. That seems present on my 5.0 Samsung test device as well, though.

Specifically, the frames are lost after the QueryCursorLoader.deliverResult method is called and in turn calls the callback FolderListFragment.onLoadFinished. The subsequent JSON deserialization in adapting the data appears to be what's hanging up the UI thread for a dozen frames or so.

Another potential cause might be the system call to startService. The docs say this

Note: Each call to startService() results in significant work done by the system to manage service lifecycle surrounding the processing of the intent, which can take multiple milliseconds of CPU time. Due to this cost, startService() should not be used for frequent intent delivery to a service, and only for scheduling significant work. Use bound services for high frequency calls.

Although the frame drops I'm seeing are not at the start of the service. I've attached a GPU profiling from my Pixel, which shows that lag spike. The green horizontal line is 16ms, for reference.
Screenshot_20190508-204712

Additionally, the Google Play console isn't indicating ANRs for the users that are running this.

Besides the Cursor redraw, I am not seeing any extreme lagginess, and the threads appear to be behaving correctly. Am I off base here?

@caleb-allen

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

With large datasets, that json deserialization happening on the UI thread might cause significant lag, but would be unrelated to the SDK level

@caleb-allen

This comment has been minimized.

Copy link
Contributor

commented May 15, 2019

@samuelclay I continue to investigate, and am not finding any issues besides the above mentioned few dropped frames from the json deserializations (which I believe to be independent of API level and the background service changes). I'm also not seeing any user reports in the forums, or lag issues reported via Google Play on the beta track.

What are your thoughts on a progressive rolling release, including the fix #1179, with close monitoring of performance issues?

@samuelclay

This comment has been minimized.

Copy link
Owner

commented May 16, 2019

Sorry, I just emailed you! Yes, that'd be a great idea. Does that mean you'll update the manifest to the latest api version?

@dosiecki

This comment has been minimized.

Copy link
Collaborator Author

commented May 16, 2019

@caleb-allen

This comment has been minimized.

Copy link
Contributor

commented May 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.