- Apr 09, 2024
-
-
Change-Id: I7b11be4b7f4d52281495a8a1c605d7df4f16bf82
-
Change-Id: I07e6a6822e3fb2c370c77b7d83e4411218bafc78
-
Change-Id: I6a52b77f52694351840a877055dddbf67363a572
-
Dhina17 authored
Change-Id: Iecb65eaa9645d37658f2c246235c9cc63287af24
-
Change-Id: I0ba720a89b3d66b9786b36bffb25624dfe226a25
-
Change-Id: I7bbb229ea43ad8b955ccb9eaf3748822efb603ec
-
Change-Id: Ie74d2f8859c03b4acef6cb9f9d770195f87c21c0
-
Change-Id: Iec832bdcd235fe6bd96ac6dc31557133d50bc423
-
- Apr 07, 2024
-
-
Dhina17 authored
Android 14.0.0 Release 31 (AP1A.240405.002.A1) * tag 'android-14.0.0_r31' of https://android.googlesource.com/platform/frameworks/base: Gate SideFpsOverlayViewBinder and DeviceEntrySideFpsOverlayInteractor on device having SFPS Return correct result Fix security vulnerability that creates user with no restrictions when accountOptions are too long. isUserInLockDown can be true when there are other strong auth requirements Added limitations for attributions to handle invalid cases Stop marking apps as privileged if they are not signed properly. Don't store invalid pkgs when migrating filters Change-Id: I3faf5c2a0cff4fb2ac5693d7658d63b885e4d6ab
-
- Apr 05, 2024
- Apr 03, 2024
-
-
Expand app rows instead of opening a settings panel. Uses the per-app volume API. Partially inspired by the patch from Android 11 "SystemUI: Add app volume row to volume dialog" by cjybyjk <cjybyjk@zjnu.edu.cn> Change-Id: I3728dfc4f39a06b96abfd571abb8858426e70f45
-
The secondary accent in light mode does not have a good contrast to the previously white icon. Previously: https://imgur.com/a/XHpDHDJ Now: https://imgur.com/a/QCk3QwC Change-Id: Ib61ad4803e0e3c6cc9163408137c7a16742922b6 Signed-off-by:
Mohammad Hasan Keramat J <ikeramat@protonmail.com>
-
Dhina17 authored
AuthService registers the authenticators only once and then onAllAuthenticatorsRegistered() callbacks are invoked. The callbacks are removed as soon as it invoked. Our LMO face unlock authenticator isn't being registered via AuthService. When we register it, the onAllAuthenticatorsRegistered() callbacks aren't available at that time so our face unlock isn't being initialized properly and end up with bugs like "Face unlock isn't working after reboot". As a workaround, we don't invoke callbacks if it's first time (from AuthService). Instead we register our face unlock here on first time to make sure callbacks are being called only after our face unlock authenticator registration. If properties aren't empty, it's from hardware face sensor. so allow to invoke callbacks regardless of the first time. Change-Id: I26238a35f09d9cb398355d9467d44cd24b0e2525
-
- Apr 02, 2024
-
-
Author: Thecrazyskull <anaskarbila@gmail.com> Date: Tue Jan 17 10:56:39 2017 -0600 SystemUI: Enable NFC tile Change-Id: Ib21f927d336fcb5e460552786828b79551b235fa Author: inthewaves <inthewaves@pm.me> Date: Sun Sep 20 14:59:10 2020 -0700 have NfcTile get an NfcAdapter directly This changes the NfcTile to not be dependent on an NfcManager giving the NfcTile an NfcAdapter. The problem with NfcTile is that the NfcService doesn't start until the device is unlocked after a reboot, but NfcTile can be created and have its state updated before the device is unlocked. The state of NfcTile depends on an NfcAdapter. The tile gets an NfcAdapter from a call to NfcAdapter#getDefaultAdapter, which gets an adapter from an NfcManager via Context#getSystemService, and NfcManager tries to get an adapter in its constructor via NfcAdapter#getNfcAdapter. If this is done before unlock, NfcService isn't started, so the constructor of NfcManager fails to get an adapter, opting to just store null. This means that the NfcManager that's _cached_ by the NfcTile's application context holds a null NfcAdapter, so subsequent calls in NfcTile to get the NfcAdapter will keep returning null. We can just have NfcTile get the NfcAdapter directly via NfcAdapter#getNfcAdapter instead of relying on an NfcManager to call the same method for us to get its default adapter. We just have to make sure we use the application context for NfcAdapter#getNfcAdapter, as per the doc comments for getNfcAdapter. This means that there's no longer an NfcManager associated with the NfcTile's application context. It doesn't look like NfcManager does anything special with the NfcAdapter anyway. It seems to just be some middle man for NfcAdapters: * The NfcAdapter field in NfcManager is final, and it doesn't do anything else with it besides have a getter method for returning it. The NfcManager seems to be a way to force third-party apps that want to get an NfcAdapter to use the application context. * NfcAdapter#getNfcAdapter manages the caching of NfcAdapters by application context in a static HashMap. NfcManager doesn't manage caching; it just calls NfcAdapter#getNfcAdapter. Change-Id: Ifafc666568a001a60baf7c8c16782dca1ee4d011 Author: Michael W <baddaemon87@gmail.com> Date: Fri Jan 15 00:03:02 2021 +0100 NfcTile: Don't create an error when editing tiles Repro: * Make sure no NfcTile is in your expanded QS (not tested what happens if it's there) * Hit the Edit-button: Error in handleSetListeningInternal java.lang.IllegalArgumentException: Receiver not registered: com.android.systemui.qs.tiles.NfcTile$1@7c00b87 at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java:1434) at android.app.ContextImpl.unregisterReceiver(ContextImpl.java:1543) at android.content.ContextWrapper.unregisterReceiver(ContextWrapper.java:664) at com.android.systemui.qs.tiles.NfcTile.handleSetListening(NfcTile.java:64) at com.android.systemui.qs.tileimpl.QSTileImpl.handleSetListeningInternal(QSTileImpl.java:371) at com.android.systemui.qs.tileimpl.QSTileImpl.access$700(QSTileImpl.java:80) at com.android.systemui.qs.tileimpl.QSTileImpl$H.handleMessage(QSTileImpl.java:496) at android.os.Handler.dispatchMessage(Handler.java:107) at android.os.Looper.loop(Looper.java:214) at android.os.HandlerThread.run(HandlerThread.java:67) * Only register or unregister the receiver if we actually need to change registered-state * Same code is in AirPlaneModeToggle.java, presumably was also added to prevent unnecessary registering/unregistering Change-Id: I6cd8f9bffccb68596b736cc0a3a38e9c12b9c489 Change-Id: Ia06b923ee15e91a9c84a806d4c69755478df2063
-
- Mar 31, 2024
-
-
Dhina17 authored
Change-Id: Iaf4c70b7fa2e21ac252e3b15de312d77846c4698
-
Dhina17 authored
Change-Id: I2cb5e278de1a32532a65ab4262c6cf615350ffb5
-
Dhina17 authored
Change-Id: Idef88d9d195003a0c90a3d286ab98cb79476ff2c
-
Dhina17 authored
Change-Id: Id4f90d3d605e58ad99f649dbfaaf2caa0c15126e
-
Dhina17 authored
Change-Id: Id463160b9f6cf3dc30aebd303d1afd9ad8194b3e
-
Dhina17 authored
Change-Id: I67aaf9dce7839f69ed7f12b0877b98f42901ce50
-
Dhina17 authored
Change-Id: Ibbd690776f4fd0efa668dbd34eed998e21846dee
-
Dhina17 authored
Change-Id: I8ad89d3ad1e9923ea6ccbfa86cd159b088783b01
-
Dhina17 authored
Change-Id: Ib1ce8ad442b174ad7e8729eefbbf53b2f8e7286d
-
Dhina17 authored
Change-Id: I8b22323826f17eb67b5f15f14b846c5a639ecff9
-
Dhina17 authored
In QPR2, DataUsageUtils methods are moved to Settings. but we need it. Change-Id: I1b37623726b1f3d0920c92c9ccfb5ac8ae38b152
-
Dhina17 authored
Change-Id: I512609a24204303b49a3aa0bb1db387ca3d1ff61
-
Change-Id: I5c57c63a494bed90bf191234206fa0eb7477c83c
-
This reverts commit b39ad20f954cda3a3ee058d685899691a97ee4f8. Change-Id: I17a689c238966a8e5e77894a4cdb3335f2e66e56
-
Co-authored-by:
Michael Bestas <mkbestas@lineageos.org> Change-Id: Ie21f0acc8ae670dcb81486d8f75b640197d40c25
-
Dhina17 authored
Views should be touched only from main thread. Change-Id: Ib2e464eba593e870d120aea7181b3ad8f4229fc6
-
Change-Id: Ia0e8846eb163f19c41819f1ee7b136df8824dffe
-
Always treat USB as disconnected if USB data signaling is turned off. Set USB functions to none, and send a state change event. The resulting behavior matches the Google Pixel series, which already reports USB as disconnected when data signaling is turned off, but the Motorola series (and maybe others that use Qualcomm's HAL) do not. Test: Manual: Set Restrict USB to Always allow. Connect to a computer. Observe the USB notification on device. Set Restrict USB to Deny. Check that the notification disappears. Search Settings for USB and tap the Connected devices > USB result. The "Use USB for" section is disabled. Issue: calyxos#2154 Change-Id: I9d8753d4dbb18012e0d40f4991ab4c15bad14de1
-
* Doesn't compile after 14 QPR2 / AP1A * Has always been an issue for CTS [CIRCULAR REFERENCE: com.android.tools.r8.internal.h: Library class vendor.lineage.trust.V1_0.IUsbRestrict implements program class android.hidl.base.V1_0.IBase] Change-Id: Id2a4ccc60d7cae6bca02e302725d982d50311278
- Mar 30, 2024
-
-
Change-Id: I2df8e15ac583ae37df328c25a0ab61d6efdb2a2b
-