Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Fix Android T deprecated WindowManager INCORRECT_CONTEXT_USAGE #28774

Merged
merged 17 commits into from
Sep 23, 2021

Conversation

GaryQian
Copy link
Contributor

Internal bug: b/199439780

Android T enforces not using an application context to get a WidowManager.

@flutter-dashboard
Copy link

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@jason-simmons
Copy link
Member

Can this provide a Display or a refresh rate to the VsyncWaiter instead of passing a WindowManager?

That appears to be the only parameter required by the VsyncWaiter

@GaryQian
Copy link
Contributor Author

Yeah, good catch, I'll modify to remove WindowManager from VsyncWaiter

VsyncWaiter.getInstance((WindowManager) appContext.getSystemService(Context.WINDOW_SERVICE))
.init();

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is specifically making sure the new code is used only for API 23+ which is when the display API was added. I guess it could be gated to only apply to T and above, I have no strong opinions either way. End goal is just to obtain the FPS float.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah ok, that's fine too then

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gating at 23 is more likely to have better test coverage as most of our testing is with API 30 and below (as of now), making this safer in the long run. I'll leave it as is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The display API was actually added in 17. I'd like to change this, is there any good reason not to?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or at least, all of the display code we're using :)

Copy link
Contributor

@dnfield dnfield Nov 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm changing this in #29800 - please add comments if it needs to be at 23 for some reason I'm missing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should hav ebeen #29800....

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see now - getSystemService was using the API 23 call instead of the one compatible with API 17. Fixing that upstream in my PR.

final Display primaryDisplay = dm.getDisplay(Display.DEFAULT_DISPLAY);
VsyncWaiter.getInstance(primaryDisplay.getRefreshRate()).init();
} else {
VsyncWaiter.getInstance(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Factor the duplicated VsyncWaiter.getInstance().init() calls out of the if/else blocks.

}
return instance;
}

@NonNull private final WindowManager windowManager;
@NonNull private final float fps;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: @NonNull can be removed

@@ -41,15 +39,14 @@ public void doFrame(long frameTimeNanos) {
}
};

private VsyncWaiter(@NonNull WindowManager windowManager) {
this.windowManager = windowManager;
private VsyncWaiter(@NonNull float fps) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto in private constructor & in the getter above

FlutterLoader flutterLoader = new FlutterLoader(mockFlutterJNI);

assertFalse(flutterLoader.initialized());
flutterLoader.startInitialization(RuntimeEnvironment.application);
Copy link

@blasten blasten Sep 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can it also ensure that context.getSystemService(Context.WINDOW_SERVIC) isn't called?

Copy link

@blasten blasten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@GaryQian GaryQian added the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Sep 22, 2021
@fluttergithubbot
Copy link
Contributor

This pull request is not suitable for automatic merging in its current state.

  • The status or check suite Linux Android Debug Engine has failed. Please fix the issues identified (or deflake) before re-applying this label.
  • The status or check suite Linux Unopt has failed. Please fix the issues identified (or deflake) before re-applying this label.
  • The status or check suite build_and_test_linux_unopt_debug has failed. Please fix the issues identified (or deflake) before re-applying this label.

@fluttergithubbot fluttergithubbot removed the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Sep 23, 2021
@GaryQian GaryQian added the waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land. label Sep 23, 2021
@GaryQian
Copy link
Contributor Author

Landing, LUCI redness is due to SkParagraph testing.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes needs tests platform-android waiting for tree to go green This PR is approved and tested, but waiting for the tree to be green to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants