This repository has been archived by the owner on Oct 29, 2024. It is now read-only.
disable screencapture detection api #463
Open
+19,599
−759
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is needed for adevtool, to reuse large ConfigDescription.to_string() function which is used for describing resource qualifiers, e.g. "values-mcc123-sw600dp-night-en".
fd '.+\.(c|cpp|cc)$' --exec sed -i 's/static JNINativeMethod/static const JNINativeMethod/'
Passes User ID to AlertWindowNotification to make sure that we can correctly load app label for the ones installed in work profile. Test: Install an app that can display over other apps in the work profile, watch the notification title and content when it's drawing over other apps. It should now display app label, rather than its package name. Change-Id: I872c0c0f6870a09c4ef1c372d7a87dec156f91fc
Signed-off-by: SuperDroidBond <superdroidbond@yahoo.com> Change-Id: I0d3a1995fa35d47e246cedef670357d31e004b50
This changeset restores the behavior in Android 13 or below to respect the Intent.EXTRA_ORIGINATING_UID set by Download Provider or Document Manager app whenever the value is valid. The bugfix provided by upstream also forgot to set the calling package for use in package installation when present, hence causing diffrent apps sharing the same uid with Download Provider app to be requested with the permission.
AOSP skips a lot of lottie animations ;( Change-Id: Ia600a3ce4dcc59c68a151eff26d253db665d8cd7
Allow Apps being added in managed work profiles, devices, and users in the event the managed profile needs sandboxed Google Play Signed-off-by: r3g_5z <june@girlboss.ceo>
Encountered with the Element app: it finishes its initial activity immediately on startup and starts a new one, which causes the OS to try to show automatic notification permission request in an infinite loop.
To succeed, userId to switch to needs to be set with setLogoutUserIdLocked(), but this is not done in both callers of this method (both of which are "End session" buttons), making them no-ops.
This reverts commit 0b925d4. Reverted commit introduced a bug: it skipped the "pkg" tag for ops with null package name. This meant that ops with null package name were serialized differently than ops with non-null package name. Tag hierarchy became the following: for non-null package name ops: "pkg" -> "uid" -> "op" -> "st" for null package name ops: "uid" -> "op" -> "st" Uid ops have the same first two tags as null package name ops started to have: "uid" -> "op". (refer to the loop over uidStatesClone elements above). This led to type confusion during deserialization that happens in readState(): null package name ops were deserialized as uid ops, through readUidOps() instead of through readPackage(). Uid ops are serialized differently than uid element inside package ops, specifically the latter skips the op mode ("m") attribute when the op mode is at its default value. Op mode attribute is read unconditionally in readUidOps(), which led to XmlPullParserException: Missing attribute "m" exception. This exception is caught in readState(), and is handled by discarding all deserialized state, which meant that all appops got reset to their default values. Subsequent commit adds skipping of ops with null package name during serialization: they are invalid, package name is defined and treated as @nonnull in multiple places. Such ops are being constructed due to another bug.
There's a bug that leads to construction of ops for invalid null package name. Package name should always be non-null, it's defined and treated as such in AppOpsService. It being null leads to crashes in system_server when appops state is serialized. Previous commit reverted a buggy workaround for this bug, add a new workaround to prevent these crashes.
There are two different APK parsers: lite and full. Lite is used to quickly obtain APK info without parsing it fully. Lite parser is missing an additional check from full parser when parsing the targetSdk, which leads to targetSdk being left at its default value (targetSdk = 1) in some cases. See com.android.server.pm.pkg.parsing.ParsingPackageUtils#parseUsesSdk() for more details. During actual package installation, full parser is used. Lite parser is used, in particular, when determining whether unattended package update is allowed, which broke unattended updates for packages with APKs that are affected by this bug.
Needed by packages_modules_Connectivity -> "enforce INTERNET permission per-uid instead of per-appId".
If the primary user had a work profile, then apps installed in primary user could see packages that were installed only in secondary user(s). They couldn't see which secondary user had which apps, only presence of such packages was revealed. This special handling of MATCH_UNINSTALLED_PACKAGES flag was added in October 2016 for compatibility with legacy launchers. It is not needed anymore, at least for popular third party launchers. Note that apps in owner user can still see apps in work profile of owner user, it's part of a public API. Also, apps that are not installed in primary user are visible in Settings -> Apps, with "Not installed for this user" subtitle. See commit 0d1fd8d and issue report GrapheneOS/os-issue-tracker#1634 for more details.
They are auto-granted unconditionally anyway during OS upgrade, app update, user profile creation etc. Before this commit, auto-grants were skipped after app install in some cases, eg when an app that declares a permission is installed after app that uses that permission.
This definition is used by the subsequent commit to add extra restrictions to the SELinux policy for the system browser.
This enables the Build.isBuildConsistent checks after tweaking the radio check to stop failing when the radio hasn't been turned on. The property used to check the radio version (gsm.baseband.version) is only set once the radio is turned on and initialized. The API documentation already claims that this is done.
Only support fetching the serial number via the new Build.getSerial() requiring the READ_PHONE_STATE permission.
The prior implementation relied on checking the init.svc.console prop, however as the console service is never launched on a user build due to it requiring ro.debuggable=1 , the UART notification will never appear. If UART is enabled the kernel cmdline is changed so that console is no longer null so use this to determine if UART is enabled and use the old method as an additional check. Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
This label is shown in header of notifications posted from system_server.
There's a known issue in AOSP 12 caused by it creating overly large intents for the work manager. It's not caused by anything done by end users and they can't work around it so avoid reporting it to them since they get a message each time it tries again.
thestinger
force-pushed
the
14
branch
10 times, most recently
from
434a169
to
38c4009
Compare
thestinger
force-pushed
the
14
branch
4 times, most recently
from
481dfac
to
8e9a025
Compare
thestinger
force-pushed
the
14
branch
6 times, most recently
from
c151c14
to
26e77ce
Compare
thestinger
force-pushed
the
14
branch
3 times, most recently
from
dd7c27b
to
edb0418
Compare
thestinger
force-pushed
the
14
branch
3 times, most recently
from
edb3b08
to
6aa5c5d
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
see GrapheneOS/os-issue-tracker#2590