IssueTracker

Here is the bugreport: https://drive.google.com/file/d/1L-tCUMv5aguqQXLYT7jHFG4B0ao6hCe6/view?usp=sharing

We have passed this to the development team and will update this issue with more information as it becomes available.

Media projection is noramlly used for wireless content streaming (casting, screensharing) or for screen recordings. It is not meant for mirroring content for connected devices. If DisplayLink would like to use media projection for their use case they would need to use something like the wakelock workaround in a foreground service (see https://developer.android.com/reference/android/os/PowerManager#SCREEN_DIM_WAKE_LOCK). In our opinion, stopping media projection on screen lock is a very natural and privacy preserving experience for typical media projection use cases.

Your previous comment (#5, now deleted) referred to "Better Together". As far as we can see, the only screen sharing mechanism there is Googlecast, which is not compatible with our USB devices.

What we are trying to do, of course, is to provide a user experience that is a close as possible to having a device driver built into the system. Each monitor needs to be represented by an Android display. Using a privileged app, we are able to achieve that since it can create virtual displays directly. But for an unprivileged app on the Play Store, the only way we can create virtual displays is by using Media Projection.

Our app has been on the Play Store since 2016 and we have been using Media Projection from Android 5 to Android 15. But since Android 13, you have been making our life increasing difficult by imposing new restrictions on Media Projection and changing the way mirroring is implemented. (See for example https://issuetracker.google.com/issues/268268869 - we are still waiting for the promised fix for this.)

Regarding possible workarounds:

• Can we use a wakelock to prevent device locking without using a deprecated API?

• Is there any way we can obtain the user's permission to re-start projection after the device has been unlocked? Owing to the strange nature of the MediaProjection API, we are obliged to launch an activity in order to obtain screen capture permission. But we are unable to launch such an activity due to the restrictions on starting activities from the background that have existed since Android 10. If you can advise us of any workaround that would allow our service to re-request capture permission when the device is unlocked then that would be better than nothing (though creating a new display isn't ideal as I've already explained above).

• The wake lock still seems to be a valid use case in your scenario. It is deprecated but still supported from what I can tell.

• we are unable to launch such an activity due to the restrictions on starting activities from the background

  Don't take this a solution, but more as some kind a investigation direction: according to https://developer.android.com/guide/components/activities/background-starts#exceptions, if you hold the SYSTEM_ALERT_WINDOW permission, you are able to launch background activities. In my opinion, this fits your scenario since you can inform the user that your application is currently sharing the screen to an external monitor.

Regarding SYSTEM_ALERT_WINDOW permission, the documentation says that "Very few apps should use this permission; these windows are intended for system-level interaction with the user." If we added this permission to our Play Store app, would it be accepted by any review that is triggered when the app is updated?

It seems that SYSTEM_ALERT_WINDOW is automatically granted to an app that is capturing the screen via MediaProjection - but only while capture is in effect! This is unhelpful, since of course we would want to launch an activity (to obtain capture permission) AFTER a MediaProjection session had ended. Thus, we would have to ask the user to grant SYSTEM_ALERT_WINDOW permission by sending Settings.ACTION_MANAGE_OVERLAY_PERMISSION, which is a somewhat convoluted process.

Regarding SYSTEM_ALERT_WINDOW permission, the documentation says that "Very few apps should use this permission; these windows are intended for system-level interaction with the user." If we added this permission to our Play Store app, would it be accepted by any review that is triggered when the app is updated?

That's not something know but feel free to link to this issue if you encounter issues when uploading the play store.

Thanks for your suggestions.

I would also like to comment on the red status bar "chip" that now appears when media projection is in progress. Although having this on the device screen is not too bad, it is of course mirrored to the captured image as well. In the case of the DisplayLink Presenter app, the chip therefore appears (much larger) on the monitor that is connected to the dock. I feel that this does detract from the user experience, especially since the chip contains a continuously changing counter, which is distracting!

Since mirroring during Media Projection is now implemented by the Window Server, there is presumably some control of which windows/layers/surfaces are included in the mirror. So perhaps you could omit the chip from the captured image?

The chip must surely affect video conferencing apps as well, since these typically have an option to share the user's screen. It will mean that the experience of everyone in a video conference will be worse if the presenter is using an Android device compared to that when the presenter is using a desktop operating system.