{ "id": "4773307e-c73f-4b93-8f5e-94264280dcfc", "created_at": "2026-04-06T00:14:19.690381Z", "updated_at": "2026-04-10T03:30:33.016338Z", "deleted_at": null, "sha1_hash": "16c4108dfe9c1649070072f4dcfcf80e7d302061", "title": "Research: Securing Android Applications from Screen Capture (FLAG_SECURE)", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 86200, "plain_text": "Research: Securing Android Applications from Screen Capture\r\n(FLAG_SECURE)\r\nPublished: 2016-04-13 · Archived: 2026-04-05 19:10:26 UTC\r\nSummary — TL, DR\r\nApps on Android and some platform services are able to capture other apps’s screens by using MediaProjection\r\nAPI. Because of the way this API implements “securing” sensitive screens, there exist some possible security\r\nissues. The best way to secure your Android app is to use FLAG_SECURE on sensitive screens and DO NOT use\r\nthe virtual keyboard (here is why).\r\nMediaProjection API\r\nSince Android 5.0, there exists a new MediaProjection API that allows apps to record videos and take\r\nscreenshots of screens belonging to other apps. The API is described as follows:\r\nAndroid 5.0 lets you add screen capturing and screen sharing capabilities to your app with the new\r\nandroid.media.projection APIs. This functionality is useful, for example, if you want to enable screen\r\nsharing in a video conferencing app. The new createVirtualDisplay() method allows your app to capture\r\nthe contents of the main screen (the default display) into a Surface object, which your app can then send\r\nacross the network. The API only allows capturing non-secure screen content, and not system audio. To\r\nbegin screen capturing, your app must first request the user’s permission by launching a screen capture\r\ndialog using an Intent obtained through the createScreenCaptureIntent() method.\r\n(On Android versions prior to 5, there are other methods such as undocumented APIs, and ADB, we are focusing\r\non Android 5+)\r\nThis API also drives several other functions in the OS:\r\nRecent apps screenshots\r\nPinning\r\nCasting to other displays\r\nGoogle Play Games, video recording feature\r\nTaking screenshots\r\nAll of these functions as well as the MediaProjection API can take screenshots and videos of other apps. For\r\napps to use the API, special permission is required, for platform features, no special permission is needed.\r\nAdditionally, any applications signed by the system key (Google apps) can use this API without permission as\r\nwell.\r\nA good open source example of an application that uses the API can be found here:\r\nhttps://wwws.nightwatchcybersecurity.com/2016/04/13/research-securing-android-applications-from-screen-capture/\r\nPage 1 of 4\n\nhttps://github.com/JakeWharton/Telecine\r\nSecure and non-secure content\r\nAs mentioned in the Google docs above, “the API only allows capturing non-secure screen content”. What exactly\r\nis “secure” and “non-secure” content?\r\nThis refers to a special flag which can be applied to views in Android, called FLAG_SECURE. It is described in\r\nAndroid docs as follows:\r\nTreat the content of the window as secure, preventing it from appearing in screenshots or from being\r\nviewed on non-secure displays\r\nSetting this flag on Android view will prevent screenshots from being taken manually, and any other app or\r\nplatform service will show a black screen. This functionality is not global for the entire app, but can be set on\r\nspecific screens which can be more sensitive, and not set on others. There is no other way or permission that can\r\nmark an entire app or any part of it from being excepted from screen capture or recording.\r\nNOTE: Even on views marked with FLAG_SECURE, the virtual keyboard is ALWAYS visible. This is due\r\nto a known Android bug which Google has so far refused to fix:\r\nhttps://code.google.com/p/android/issues/detail?id=129285\r\nHow screen capture really works in Android\r\nThe term “secure” as used in this context does not mean that the content of the app cannot be captured, rather that\r\nit cannot be “viewed on non-secure displays”. This is because screen capture and the concept of secure / non-secure isn’t what developers may think it is.\r\nBehind the scenes, this API and related platform services use the concept of Casting (similar to AirPlay). Apps\r\nthat capture screenshots and record videos, must create a virtual display to which then the device content is cast to.\r\nThe FLAG_SECURE flag is also not used for security but rather means copyrighted content in context of DRM\r\nand displays — i.e. secure content would be something like a DVD, and a secure display would be an HDTV.\r\nThis is clear on the device itself — when an app begins to record the screen, the cast icon is turned on in the\r\nnotification bar. This is also clear from the Android source code and this doc:\r\nDisplay flag: Indicates that the display has a secure video output and supports compositing secure\r\nsurfaces. If this flag is set then the display device has a secure video output and is capable of showing\r\nsecure surfaces. It may also be capable of showing protected buffers. If this flag is not set then the\r\ndisplay device may not have a secure video output; the user may see a blank region on the screen\r\ninstead of the contents of secure surfaces or protected buffers.\r\nThat would means that an Android device casting to a DRM-protected display like a TV would always display\r\nsensitive screens, since the concept of secure really means “copyrighted”. For apps, Google forestalled this issue\r\nby preventing apps not signed by the system key from creating virtual “secure” displays, but not for physical\r\nhttps://wwws.nightwatchcybersecurity.com/2016/04/13/research-securing-android-applications-from-screen-capture/\r\nPage 2 of 4\n\ndevices. There is also an existing Android bug asking for the concept of DRM and screen security to be separated\r\ninto different flags:\r\nhttps://code.google.com/p/android/issues/detail?id=93026\r\nSecurity issues with the current API\r\nFirst of all, a basic foundation of mobile app security is a clear separation between apps. One Android app is\r\nshould never able to read the preferences, data or capture cloud notifications of another app. This paradigm breaks\r\ndown in case of screen capture/recording. An app gaining access to the MediaProjection API or any of the\r\nplatform services using it, is able to capture screen output from other apps including PIN numbers,\r\npasswords, credit card numbers, etc.\r\nSecond, by using a flag used for marking copyrighted content, it would make it easier to subvert the system. Some\r\nways this can be subverted include:\r\nGaining permissions to create a virtual display marked as secure would show all secure content. Right now\r\nthis is preventable by using the system key, but a rooted phone or some other way that fools the system into\r\ncreating such display would by pass this protection.\r\nAlso, casting to a physical secure display, or perhaps a wireless one, would also display content\r\nThird, even with the FLAG_SECURE in use, some parts of the screen can still be captured. The virtual keyboard\r\nis one existing example, but there may be others (perhaps notifications?).\r\n[ADDED 06/24/2016: Mark Murphy from CommonsWare points out several other issues with FLAG_SECURE\r\nchild objects – see his blog post here]\r\nFourth, there is no clear indication to the user they are being recorded other than the cast icon. Clicking on the\r\nicon shows no devices since virtual devices aren’t going to be listed. A better warning may be needed.\r\nA better solution as suggested in this bug report, would be to define a separate flag and never allow any app or\r\nsystem service to see its output under any reason, and also to blank out the entire screen even if other apps or\r\nservice display anything on it. An even better solution would be to make this opt-in for apps, instead of opt-out.\r\nAttack vectors\r\nThere are several possible avenues of attack which would result in an app being installed on a user’s phone\r\nrecording their app activity. These include:\r\nMalicious apps in the app store that masquerade as legit casting apps requiring record permission — since\r\nusers don’t know that casting apps can also record their screen\r\nRemote install via compromised desktop as described in this paper\r\nOverlaying permission screens as described here\r\nTo record even non-secure screens, the following can be tried but they are not practically feasible:\r\nOn rooted phones, creating a virtual display marked as “secure”\r\nhttps://wwws.nightwatchcybersecurity.com/2016/04/13/research-securing-android-applications-from-screen-capture/\r\nPage 3 of 4\n\nFooling the system into thinking that a given app is a system app, allowing it to create secure displays\r\nAll of these would result in an app sitting on the phone and recording user activity. However, other than the last\r\ntwo methods, FLAG_SECURE views would not be recordable, although the virtual keyboard is. The only\r\nindicator to the user would be the cast icon, but when they click on it, no devices would be listed.\r\n[ADDED 2020-03-23: As per this excellent blog post from Yanick Fratantonio, FLAG_SECURE will NOT\r\nprotect against attacks using accessibility services (a11y)]\r\nAttacks in the Wild\r\nSome examples of these type of attacks happening in the wild:\r\nJuly 2018 – Panoptispy Study – see here, here, here and here\r\nJuly 2018 – Anubis Android malware – see here and here\r\nConclusion — Protect Your Apps\r\nTo protect your apps from being recorded by other apps, FLAG_SECURE should be used on any views containing\r\nsensitive data. Additionally, since the virtual keyboard is also vulnerable, it is recommended that these screens\r\neither use a custom keyboard, or if feasible to use an on-screen custom layout (for numeric input like PIN\r\nnumbers).\r\nWe have surveyed many of the top apps in the Google Play store, and many of them including some Google-owned apps do not use FLAG_SECURE or if they do, do not secure the keyboard.\r\nWe also hope that Google would lock down this API and solve the issues highlighted in this article.\r\nCredits\r\nResearched and written by Yakov Shafranovich.\r\nReferences\r\nGoogle CID: 3–5606000008769\r\nSource: https://wwws.nightwatchcybersecurity.com/2016/04/13/research-securing-android-applications-from-screen-capture/\r\nhttps://wwws.nightwatchcybersecurity.com/2016/04/13/research-securing-android-applications-from-screen-capture/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://wwws.nightwatchcybersecurity.com/2016/04/13/research-securing-android-applications-from-screen-capture/" ], "report_names": [ "research-securing-android-applications-from-screen-capture" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434459, "ts_updated_at": 1775791833, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/16c4108dfe9c1649070072f4dcfcf80e7d302061.pdf", "text": "https://archive.orkl.eu/16c4108dfe9c1649070072f4dcfcf80e7d302061.txt", "img": "https://archive.orkl.eu/16c4108dfe9c1649070072f4dcfcf80e7d302061.jpg" } }