Update ComposableBitmapRendererImpl.kt to use the context from Presentation Layer

[riggaroo]

Switch to the height and width of the context for the virtual display, due to StrictMode reporting issues with incorrect context usage.

com.google.android.libraries.strictmode.StrictModePolicyViolation: INCORRECT_CONTEXT_USE
  at android.os.StrictMode.onIncorrectContextUsed(StrictMode.java:2491)
  at android.os.StrictMode.assertConfigurationContext(StrictMode.java:2527)
  at android.view.ViewConfiguration.get(ViewConfiguration.java:641)
  at android.view.View.<init>(View.java:6013)
  at android.view.View.<init>(View.java:6146)
  at android.view.ViewGroup.<init>(ViewGroup.java:716)
  at android.view.ViewGroup.<init>(ViewGroup.java:712)
  at androidx.compose.ui.platform.AbstractComposeView.<init>(ComposeView.android.kt:60

cc @yschimke

[gemini-code-assist]

Summary of Changes

Hello @riggaroo, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a StrictModePolicyViolation related to incorrect context usage when rendering composables to a bitmap. The changes ensure that the virtual display and ComposeView are initialized with the correct context and display dimensions, specifically by leveraging the context from the Presentation Layer. This resolves runtime errors and improves the robustness of the bitmap rendering functionality.

Highlights

• Corrected Virtual Display Dimensions: The ComposableBitmapRendererImpl now correctly initializes the virtual display with the actual width, height, and density from the application's display metrics. This resolves StrictMode warnings related to incorrect context usage when creating virtual displays.
• Switched to Presentation Layer Context for ComposeView: The ComposeView used for rendering composables to a bitmap now explicitly uses the context provided by the Presentation Layer, ensuring proper context association and preventing potential StrictMode violations.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request successfully addresses a StrictMode violation by using the correct context when creating a VirtualDisplay and ComposeView. The changes to use the display metrics for the virtual display and the presentation context for the ComposeView are appropriate.

However, I've identified a critical pre-existing issue in the useVirtualDisplay function regarding potential resource leaks. It's important to address this to prevent memory issues and ensure application stability. My detailed comment explains the issue and suggests a path to resolution.

[gemini-code-assist]

While these changes correctly fix the StrictMode violation, the surrounding useVirtualDisplay function has a critical flaw regarding resource management. If createVirtualDisplay or the callback on line 97 throws an exception, the release() methods for virtualDisplay, surface, and texture will not be called, leading to resource leaks.

It is crucial to wrap the resource allocation and usage in a try...finally block to guarantee that release() is always called, regardless of exceptions.

try {
    // resource allocation and usage
} finally {
    // resource release
}

Additionally, getSystemService can return null, which should be handled to prevent crashes. The non-null assertion (!!) on virtualDisplay (line 97) is also redundant as createVirtualDisplay returns a non-null type.