New Crowdin updates#1323
Open
gwolf2u wants to merge 998 commits into
Open
Conversation
Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Credits: - Iconify for clock styles - Infinity X for UserProfileUtils Co-authored-by: DrDisagree <crazymahmud08@gmail.com> Co-authored-by: tejas101k <tejassingh649@rediffmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Co-authored-by: Idc <59904122+IDontCare-05@users.noreply.github.com> Co-authored-by: spkal01 <kalligeross@gmail.com> Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
- Move listener/receiver registration from constructor to onAttachedToWindow with mCallbacksRegistered guard to prevent double-registration and early context leaks - Add missing AOD tick (mAodTickRunnable) so clock time updates correctly while dozing instead of freezing - Add AOD opacity cap (70) so clock doesn't burn OLED panels when opacity is set high - Add clock size scaling support (CLOCK_SIZE_KEY, applyClockScale, applyClockScaleAfterLayout, getScaleFactor) - Add applyClockAlpha and wire it into onDozingChanged, opacity tuning, and updateClockAppearance — opacity was read but never applied in the old impl - Consolidate Handler instances into single mHandler on Looper.getMainLooper(), drop deprecated bare new Handler() - Fix ViewStub re-inflation crash on style change by caching mClockStub and mClockContainer references - Fix BroadcastReceiver to force-update on ACTION_SCREEN_ON without the rate-limit gate, and route other actions correctly - Fix onDozingChanged to apply color and alpha on AOD entry/exit in addition to burn-in protection - Fix updateTextClockViews to check root node for TextClock in addition to children - Add mCenterClocks array and isCenterClock() for the full 44-entry layout list so center-aligned clocks get correct gravity applied - Rename updateTextClockColor -> applyTextClockColor to match upstream naming convention and call signature - Guard onDetachedFromWindow cleanup with mCallbacksRegistered and remove AOD tick callbacks alongside burn-in callbacks Co-authored-by: Joey <joey@evolution-x.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: HDzungx <hdzungx@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: HDzungx <hdzungx@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: HDzungx <hdzungx@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: HDzungx <hdzungx@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
If proc is null, other threads may remain in the “Waiting” state indefinitely within the handleApplicationStrictModeViolation method. Test: monkey test Flag: EXEMPT bugfix Bug: 494493385 Change-Id: Ideb98538203f5d0855300424e9aae54358d19a76 Signed-off-by: luanzhuang <luanzhuang@xiaomi.corp-partner.google.com>
bug:494502685 direct byte buffer was not released, causing a memory leak. Change-Id: Ida8e32589d666901517c4e4eb537748addb213d5 Signed-off-by: Aiguo <aiguo.feng@amlogic.corp-partner.google.com>
Design Concept attribution: BlissRoms/platform_frameworks_base@d7be9f3 BlissRoms/platform_frameworks_base@7a8a026 BlissRoms/platform_frameworks_base@a50e10c Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
* Treat classic tiles as icon only so that we apply color and bounceable animation correctly. Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Ref: https://github.com/BootleggersROM/packages_overlays_Shishufied/tree/queso/QSTiles * Regenerate path and adapt for our implementation. * Add separate outline tile color to make it distinct. Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
[neobuddy89: Do not change style, only weight] Signed-off-by: Ghosuto <clash.raja10@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Keep the discrete steps but hide the visual tick marks for a more cleaner look. Change-Id: I3585f62d0126afb00223104192a4cedfcdf13cbe Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Treat empty attribution tags the same way as null in isAttributionInPackage(). This avoids repeated AppOps error logs from pre-S apps that pass an empty string attribution tag even though they could not declare <attribution> entries in their manifest. Change-Id: Ieecdba9130328ab9de3c1e16d9b2100b288ce492 Signed-off-by: Quince <quinceroms@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Only log and start IME hide tracking when the IME is actually requested visible or when a user-controlled IME animation is active. This avoids repeated hide(ime()) log spam and unnecessary ImeTracker token allocation when clients keep asking to hide an already hidden IME. Change-Id: Iff27ec1b4c7c8236346c18996b776f34612c8975 Signed-off-by: Quince <quinceroms@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Remove the delayed dismiss message when LogAccessDialogActivity is destroyed and guard the final dialog dismiss in onClick(). This prevents stale timeout callbacks from interacting with a detached DecorView after configuration changes. Change-Id: Ib8abe68cb4c7aa95dd90b9c67d1b6ac7cd3706b3 Signed-off-by: Quince <quinceroms@gmail.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Change-Id: I64d455835389acb2e591ff0b623797e1e122f06d Signed-off-by: rmp22 <195054967+rmp22@users.noreply.github.com> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
During USB headset disconnection, AudioDeviceBroker synchronously restores mBluetoothA2dpEnabled=true, but mGlobalBluetoothA2dpOn in MediaRouterService is only updated later via the asynchronous dispatchAudioRoutesChanged callback. A playback state change in this transient window causes restoreBluetoothA2dp() to read the stale mGlobalBluetoothA2dpOn=false and call setBluetoothA2dpOn(false), overriding the already-restored A2DP state and suppressing Bluetooth audio output. Fix by cross-checking with AudioService.isBluetoothA2dpOn() before setting A2DP off. When the two states are inconsistent (local says off but AudioService says on), skip the stale request. Bug: 498786084 Test: 1. Connect Bluetooth headphones and play music. 2. Plug in USB headphones. 3. Unplug USB headphones. Flag: EXEMPT bug fix Change-Id: I98a64166f0f130347cb90cebf362c6d1a9935024 Signed-off-by: chenxin20 <chenxin20@xiaomi.com>
…in scenarios involving dual instances of the app. Perform a backup for each user. Test: atest Bug:498471068 Change-Id: Ib3cd2fbd58a8039a9c0a598e9d6346ff3b00e01c Signed-off-by: luanzhuang <luanzhuang@xiaomi.corp-partner.google.com>
… for lock screen unlocking Bug: 499150034 Test: 1. Set PIN unlock method 2. Lock it and press the unlock button 3. Intentionally enter the wrong password and wait for the countdown. 4. During the countdown, repeatedly open and close the unlock disc 5. Check if the countdown is correct Change-Id: I7c15a95a7871a04ec0a71f5405be2d014aadfe45
Change-Id: I2aaa9e526b6f1a35d45e96b6d23e3db972d82733 Signed-off-by: Joey Huab <joey@evolution-x.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
A leak can occur for any app that uses StrictMode#enableDefaults or sets
StrictMode.VmPolicy.Builder's detectBlockedBackgroundActivityLaunch or detectAll. If any of those
are called or set, every call to StrictMode#setVmPolicy (this is used in core framework code like
LoadedApk) will trigger StrictMode#registerBackgroundActivityLaunchCallback. This registers a brand
new callback every time.
In system_server, these new callbacks are just stored in an ArrayMap in
BackgroundActivityStartController's addStrictModeCallback which uses the IBinder as the map key.
Since every new BackgroundActivityLaunchCallback is a distinct IBinder, containsKey(callback) never
returns true for a new callback instance from StrictMode.
For userdebug/eng builds, this leak can also occur in any bundled system app due to the logic in
StrictMode#initVmDefaults. In particular, SystemUI can crash because of this leak. When such a crash
occurs, the following is printed out (UID 10126 is SystemUI):
V Binder : BinderProxy descriptor histogram (top 10):
V Binder : # 1: android.app.IBackgroundActivityLaunchCallback x5698
V Binder : # 2: android.content.IIntentReceiver x471
V Binder : # 3: android.content.IContentProvider x304
V Binder : # 4: android.database.IContentObserver x237
V Binder : # 5: android.app.IApplicationThread x140
V Binder : # 6: com.android.internal.os.IResultReceiver x135
V Binder : # 7: android.app.IUnsafeIntentStrictModeCallback x92
V Binder : # 8: x86
V Binder : # 9: <cleared weak-ref> x83
V Binder : # 10: <proxy to dead node> x54
D Binder : Per Uid Binder Proxy Counts:
...
D Binder : UID : 10126 count = 6006
...
E BpBinder: Too many binder proxy objects sent to uid 1000 from uid 10126 (... proxies held)
E ActivityManager: Uid 10126 sent too many Binders to uid 1000
...
I ActivityManager: Killing 2145:com.android.systemui/u0a126 (adj -800): Too many Binders sent to SYSTEM
I am_kill : [User=0,PID=2145,Process Name=com.android.systemui,OomAdj=-800,Reason=Too many Binders sent to SYSTEM,Rss=477156B]
StrictMode#initVmDefaults calls builder.detectAll() for all bundled system apps on userdebug and eng
builds. detectAll() includes DETECT_VM_BACKGROUND_ACTIVITY_LAUNCH_ABORTED. SystemUI is a bundled
system app, so it gets this flag at startup. With this flag, every call to StrictMode#setVmPolicy
will trigger StrictMode#registerBackgroundActivityLaunchCallback.
A hot path is in LoadedApk which SystemUI calls very often when managing notification UI. In
LoadedApk#canAccessDataDir, the following pattern is used which should demonstrate how this leak
can happen:
StrictMode.VmPolicy old = StrictMode.allowVmViolations();
try {
// StrictMode violation code
} finally {
StrictMode.setVmPolicy(old); // re-registers a new BAL callback every time
}
It's not unexpected for other apps to be following this pattern as well.
The following is a stacktrace of how SystemUI adds new BAL callbacks. This runs on every
notification that gets posted:
```
W StrictMode: java.lang.Throwable
W StrictMode: at android.os.StrictMode.registerBackgroundActivityLaunchCallback(StrictMode.java:2230)
W StrictMode: at android.os.StrictMode.setVmPolicy(StrictMode.java:2222)
W StrictMode: at android.app.LoadedApk.setVmPolicy(LoadedApk.java:875)
W StrictMode: at android.app.LoadedApk.canAccessDataDir(LoadedApk.java:1170)
W StrictMode: at android.app.LoadedApk.createOrUpdateClassLoaderLocked(LoadedApk.java:962)
W StrictMode: at android.app.LoadedApk.getClassLoader(LoadedApk.java:1183)
W StrictMode: at android.app.ActivityThread.getTopLevelResources(ActivityThread.java:3169)
W StrictMode: at android.app.ApplicationPackageManager.getResourcesForApplication(ApplicationPackageManager.java:2199)
W StrictMode: at android.app.ApplicationPackageManager.getResourcesForApplication(ApplicationPackageManager.java:2182)
W StrictMode: at android.app.ApplicationPackageManager.getResourcesForApplication(ApplicationPackageManager.java:2218)
W StrictMode: at android.graphics.drawable.Icon.loadDrawableAsUser(Icon.java:616)
W StrictMode: at com.android.systemui.statusbar.StatusBarIconView.getIcon(StatusBarIconView.java)
W StrictMode: at com.android.systemui.statusbar.StatusBarIconView.updateDrawable(StatusBarIconView.java)
W StrictMode: at com.android.systemui.statusbar.StatusBarIconView.set(StatusBarIconView.java)
W StrictMode: at com.android.systemui.statusbar.notification.icon.IconManager.setIcon(IconManager.java)
W StrictMode: at com.android.systemui.statusbar.notification.icon.IconManager.createIcons(IconManager.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.inflation.NotificationRowBinderImpl.inflateViews(NotificationRowBinderImpl.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.NotifInflaterImpl.inflateViewsImpl(NotifInflaterImpl.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.coordinator.PreparationCoordinator.inflateEntry(PreparationCoordinator.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.coordinator.PreparationCoordinator.inflateRequiredNotifViews(PreparationCoordinator.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.coordinator.PreparationCoordinator.inflateRequiredGroupViews(PreparationCoordinator.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.coordinator.PreparationCoordinator$$ExternalSyntheticLambda2.onBeforeFinalizeFilter(PreparationCoordinator.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.ShadeListBuilder$$ExternalSyntheticLambda12.accept(ShadeListBuilder.java)
W StrictMode: at com.android.systemui.util.NamedListenerSet.forEachTraced(NamedListenerSet.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.ShadeListBuilder$$ExternalSyntheticLambda7.run(ShadeListBuilder.java)
W StrictMode: at com.android.systemui.statusbar.notification.collection.NotifPipelineChoreographerImpl$frameCallback$1.doFrame(NotifPipelineChoreographerImpl.kt)
W StrictMode: at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1628)
W StrictMode: at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1639)
W StrictMode: at android.view.Choreographer.doCallbacks(Choreographer.java:1235)
W StrictMode: at android.view.Choreographer.doFrame(Choreographer.java:1160)
W StrictMode: at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1613)
```
There's also another path from
com.android.systemui.statusbar.notification.collection.coordinator.MediaCoordinator.shouldFilterOut
not shown here.
The SystemUI crash only occurs on userdebug/eng, but any app using the BAL StrictMode methods or the
StrictMode#enableDefaults will have this leak as well.
Note that StrictMode's BackgroundActivityLaunchCallback only calls static methods, so there's really
no point in making new instances for every call. system_server doesn't do anything with newly added
callbacks other than add it to an ArrayMap and link a death recipient. This also follows the
approach of StrictMode's existing usage of sUnsafeIntentCallback.
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
No description provided.