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

Conversation

@gaaclarke
Copy link
Member

@gaaclarke gaaclarke commented Sep 21, 2021

Created a test runner that can execute Android embedder code on an Android device. This matches the capabilities that we have for iOS with iOS with IosUnitTests. Before this all c++ files in shell/platform/android were unable to be unit tested. Since scenario_app isn't working for Android there is was no test coverage for these files in the engine repository.

This will be used to create the unit tests to resolve flutter/flutter#90398. The AndroidShellHolder test is hitting the code that we were concerned about.

We previously discussed something that would execute on the host platform with SwiftShader but that would be more work to get android code compiling for the host platform and be less useful since this actually runs on the target device.

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on
    writing and running engine tests.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@google-cla google-cla bot added the cla: yes label Sep 21, 2021
@gaaclarke gaaclarke changed the title added unit tests that run on android devices added unit tests for the android embedder that run on android devices Sep 21, 2021
@gaaclarke gaaclarke force-pushed the android_unittests branch 3 times, most recently from a882bdd to fcadf81 Compare September 21, 2021 22:59
@gaaclarke gaaclarke marked this pull request as ready for review September 21, 2021 23:13
display, config_, reinterpret_cast<EGLNativeWindowType>(window->handle()),
attribs);
return std::make_unique<AndroidEGLSurface>(surface, display, context_);
if (window->IsOffscreen()) {
Copy link
Member

Choose a reason for hiding this comment

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

This is imprecise - an AndroidNativeWindow can be backed by a real window surface that is positioned offscreen.

Change this to something like IsFakeWindow and emphasize that this is only provided to support tests and will not happen on a real device.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done, the docstring mentions it's for tests.

if (window->IsOffscreen()) {
const EGLint attribs[] = {EGL_WIDTH, 1, EGL_HEIGHT, 1, EGL_NONE};

EGLSurface surface = eglCreatePbufferSurface(display, config_, attribs);
Copy link
Member

Choose a reason for hiding this comment

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

Call AndroidContextGL::CreatePbufferSurface which is identical to this code.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

remote_path = '/data/local/tmp'
remote_tests_path = os.path.join(remote_path, test_runner_name)
RunCmd(['adb', 'push', tests_path, remote_path], cwd=buildroot_dir)
RunCmd(['adb', 'shell', remote_tests_path])
Copy link
Contributor

Choose a reason for hiding this comment

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

How does this validate failure or pass?

Copy link
Member Author

Choose a reason for hiding this comment

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

adb shell forwards the exit code which RunCmd grabs.

Comment on lines +207 to +209
if (window->IsFakeWindow()) {
return CreatePbufferSurface();
} else {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need to create a PBuffer surface?

How confident can we be that we're testing what we even care about here?

Is there any possible way we could avoid this code in production code?

Copy link
Member Author

Choose a reason for hiding this comment

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

The tests in this PR are just very simple setup and teardown. This is more about setting up the infrastructure to make more interesting tests that do assert more things.

Copy link
Member Author

Choose a reason for hiding this comment

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

As far as the IsFakeWindow question, I looked into it. I didn't see a way to do it that wasn't a significant refactor. That's sometimes the problem when you add tests after the fact versus build them up with tests.

You could transfer creating the surface to the window, but that would leak egl calls outside of the AndroidContextGL. I'm open to any suggestion I might have overlooked.

Copy link
Member Author

Choose a reason for hiding this comment

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

Why do we need to create a PBuffer surface?

The code assumes a surface, it will crash if you don't have one. We don't have a window so our only option is to make a fake pbuffer surface.

Copy link
Contributor

@dnfield dnfield left a comment

Choose a reason for hiding this comment

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

Have you considered creating an integration test in FTL that would then scan the logs for the specific error/warning that Android emits when the context is collected on the wrong thread?

@dnfield
Copy link
Contributor

dnfield commented Sep 23, 2021

or - in addition to scanning the logs, you could add a FML_DCHECK and test with an unopt build.

@gaaclarke
Copy link
Member Author

Have you considered creating an integration test in FTL that would then scan the logs for the specific error/warning that Android emits when the context is collected on the wrong thread?

I didn't really look into it because there is a broader need for unit tests for these files and it will be adequate for my purposes.

@gaaclarke
Copy link
Member Author

@jason-simmons friendly ping

@dnfield One thing I forgot to mention was the need to run the unit tests in the debugger.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Share the GrDirectContext across engine instances on Android

3 participants