[Android] Implement setting content sensitivity on Android - #158473

Overview

Implements setting content sensitivity on Android via a new widget called SensitiveContent that currently will only function on Android.

How it's implemented

There are three different content sensitivity levels: autoSensitive, sensitive, notSensitive. All except autoSensitive behave as their Android counterpart level behaves (see links on the levels); for Flutter, autoSensitive will behave the same as notSensitive though it is implemented as if it works (see #160879 for more details.

In any given Flutter view, each SensitiveContent widget sets a content sensitivity level and there may be multiple SensitiveContent widgets in the widget tree at a time, but only the most severe content sensitivity level in the tree will be maintained in order to ensure secure content remains obscured during screen projection. This means that even widgets that are not visible may still impact the overall content sensitivity of the entire Flutter view (see #160051 for more details).

Under the hood, the implementation uses method channels. Theoretically, this could cause a delay in setting the content sensitivity level and a Flutter view being obscured during screen projection on time, so we will investigate using JNIgen in the future (see #160050 for more details). Over the method channel, the framework will send a Flutter view ID and content sensitivity level to the engine to set the expected content sensitivity level for the view.

Timeline

Required for feature shipping

• Land this PR with the method channel implementation of content sensitivity.

Short-term follow up tasks

• Ensure every FlutterView has a unique ID for the native SensitiveContentPlugin to identify them by: [Android] Make FlutterView IDs instance variables instead of a static one #162685
• Add SensitiveContent widget to relevant Flutter widgets: [Android] Add SensitiveContent widget to Flutter widgets that have potential security vulnerabilities during screen share #167302

Long-term follow up tasks

• Convert this PR to use JNIgen: [Android] Modify sensitive content support implementation to use JNIgen #160050. Verify no frames are dropped, revealing sensitive content during media projection: [Android] Verify SensitiveContent widget potential frame drops are not visible #164820.

Stretch goals

• Make the SensitiveContent widget sensitive to the visibility of child widgets: [Android] Un-mark sensitive content when it is not visible on screen #160051
• Implement autoSensitivity mode: [Android] Investigate implementing autoSensitive sensitive content mode #160879
• Investigate backwards compatibility for APIs < 35: [Android] Consider implementing backwards compatibility for sensitive content protection #159208

Open questions

• Is it okay to hard-code the FlutterActivity and FlutterFragment view IDs? Does this impact add-to-app in any way? I assume we would need extenders of those classes to use a different view ID than the hardcoded one. Approach not used.
• Should we expose autoSensitive for now? If so, what behavior should it have? Exposing autoSensitive as if it works.

One way to test this PR (rough steps)

1. Create a Flutter app that has some number of SensitiveContent widgets.
2. Run the app on an emulator/device that runs API 35 and has the Google meets app downloaded.
3. Start a Google meets meeting and screen share (works with full screen and single app mode).
4. Join the Google meets meeting from another device and witness a blacked out screen if content has been marked sensitive.

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, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.