Comparing changes

@Herna1994

Inspiration from MiUI, iOS and Dil3mm4 Change-Id: I8bddda04c83c995bec82e9493017db69bd460b34 Co-Authored-By: Andrew Fluck <andrew@aospa.co> Co-Authored-By: rituj <ritujbeniwal@gmail.com> Co-Authored-By: Jyotiraditya <jyotiraditya@aospa.co> Co-Authored-By: Akash Srivastava <akashsrivastava@aospa.co> Co-Authored-By: 00day0 <therandomuser11@gmail.com> Co-authored-by: Kshitij Gupta <kshitijgm@gmail.com> SystemUI: allow devices override audio panel location Some devices have volume buttons on left side and it not fancy if volume panel will be at right side. You can override panel location using overlay for SystemUI:  <bool name="config_audioPanelOnLeftSide">true</bool> * @Herna1994 : Fixed animation on left side panel. * @Herna1994 : Adapted to Android 10. Signed-off-by: Hernán Castañón <herna@paranoidandroid.co> Change-Id: I4f111ec43c436b1c5ff81afea3f5d755bc8e7668 Volume panel: Do the same with less Change-Id: If41456f71ffd18466166e7b4120ff34d9e6f5a46 Signed-off-by: Hernán Castañón Álvarez <herna@paranoidandroid.co> SystemUI: Introduce user interface for Alert Sliders Ported from OxygenOS and reworked for our alert slider implementation. We target AudioManager instead of Zen, icons are also the same as aosp and the dialog uses the material theme as well as support for our themes. To use, the alert slider config must be enabled. By default, the dialog shows on the left side. To move it to the right side, set the location config to 1. Change-Id: Ie1954a44cc5242c95a731abd7404379ea638fe70 policy: Add support for device alert sliders * Provide support for alert slider hardware. * Ability to swap order of alert slider within system setting. * Enable setting config_hasAlertSlider to true and defining proc nodes for state path and UEvent match path. * Contributors: @Thecrazyskull @carlosavignano TODO> SystemUI integration. Forward ported to Pie by @Sirhc95 Change-Id: I46f594923aedf3445ee9cecb16a90c4963f78a89 SystemUI: Improve alert slider dialog - Convert px to dip - Modify the dialog to match toast - Fix positioning for OP7 Pro slider - Remove unused dimens and drawables Edit: set position values to 0 for neutrality. They should be adapted by overriding in each device tree. Change-Id: I0dfb705843f52cdea470993d05a7bdedc10750f4 base: SystemUI: hide ringer button if alert slider is present. Signed-off-by: Hernán Castañón Álvarez <herna@paranoidandroid.co> Change-Id: Ia0b3b095eed35b87bd81e2f96622391949f5b721 SystemUI: Redesign volume dialog Inspiration from MiUI, iOS and Dil3mm4 Change-Id: I8bddda04c83c995bec82e9493017db69bd460b34 Co-Authored-By: Andrew Fluck <andrew@aospa.co> Co-Authored-By: rituj <ritujbeniwal@gmail.com> Co-Authored-By: Jyotiraditya <jyotiraditya@aospa.co> Co-Authored-By: Akash Srivastava <akashsrivastava@aospa.co> Co-Authored-By: 00day0 <therandomuser11@gmail.com> Co-authored-by: Kshitij Gupta <kshitijgm@gmail.com> base: Redo expanded volume panel for 10.x [ @HrX03 | @AgentFabulous - POSP ] - Google nuked expanded volume panel in pie. Redo the current implementation to bring this back from the past and dejank it. - Back to Android 8.x functionality! Change-Id: Ie4931a4ae09483ba737a74fc32ed0a1f6acf105d Co-authored-by: Kshitij Gupta <kshitijgm@gmail.com> Signed-off-by: Arian <arian.kulmer@web.de> SystemUI: VolumePanel: Version 1.1 * Add support for unlinked notification volume * Fix progress bar inconsistencies when switching ringer modes * Some minor animation tweaks Change-Id: I31f87aacb7fbb445dd3b03ceb5064263e5af4836 VolumeDialogImpl: fix ConcurrentModificationException SDB: it's happening to only a few users and let make those fc free msg: java.util.ConcurrentModificationException stacktrace: java.util.ConcurrentModificationException at java.util.ArrayList$Itr.next(ArrayList.java:860) at com.android.systemui.volume.VolumeDialogImpl.updateMediaOutputViewH(VolumeDialogImpl.java:905) at com.android.systemui.volume.VolumeDialogImpl.access$4800(VolumeDialogImpl.java:120) at com.android.systemui.volume.VolumeDialogImpl$H.handleMessage(VolumeDialogImpl.java:1912) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loop(Looper.java:223) at android.app.ActivityThread.main(ActivityThread.java:7657) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:594) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947) VolumePluginManager: Fix fc for stock panel Change-Id: Ib0f6340ac7fea08abc637a1c3391a58cc4f1dfb6 VolumeDialogImpl: Reschedule the timeout on clicks on captions Change-Id: Ie98813a91396f3c3a84aeac8a609071c5cc315f6 VolumePanel: Fix glitchy ringer and notif bar when switching modes Co-Authored-By: Andrew Fluck <andrew@aospa.co> Co-Authored-By: rituj <ritujbeniwal@gmail.com> Co-Authored-By: Jyotiraditya <jyotiraditya@aospa.co> Co-Authored-By: Akash Srivastava <akashsrivastava@aospa.co> Co-Authored-By: 00day0 <therandomuser11@gmail.com> Co-authored-by: Kshitij Gupta <kshitijgm@gmail.com> Signed-off-by: rituj <ritujbeniwal@gmail.com> Signed-off-by: Arian <arian.kulmer@web.de> Signed-off-by: rituj <ritujbeniwal@gmail.com> Signed-off-by: althafvly <althafvly@gmail.com> Change-Id: I585c7366cb99c0c3baf699a5a553e77da895d195

From motorola/nio_retcn/nio:11/RRN31.Q1-20-17-1/1cbc0:user/release-keys Change-Id: I493fb57047ae7b9fe7ce775667207b60889070ba FaceService: Nuke useless call to getAuthenticatorId That value is static, so the call isn't needed. That fixes also a logspam: 2021-03-06 21:11:09.553 1767-1767/? W/Binder: Outgoing transactions from this process must be FLAG_ONEWAY java.lang.Throwable at android.os.BinderProxy.transact(BinderProxy.java:511) at com.android.internal.util.custom.faceunlock.IFaceService$Stub$Proxy.getAuthenticatorId(IFaceService.java:335) at com.android.server.biometrics.face.CustomFaceService.getAuthenticatorId(CustomFaceService.java:275) at com.android.server.biometrics.face.FaceService.updateActiveGroup(FaceService.java:1190) at com.android.server.biometrics.BiometricServiceBase.loadAuthenticatorIds(BiometricServiceBase.java:1183) at com.android.server.biometrics.face.CustomFaceService$FaceServiceConnection.lambda$onServiceConnected$0$CustomFaceService$FaceServiceConnection(CustomFaceService.java:427) at com.android.server.biometrics.face.-$$Lambda$CustomFaceService$FaceServiceConnection$xfTT3adGf0joHpCrnXRrbjd4jD8.run(Unknown Source:2) at android.os.Handler.handleCallback(Handler.java:938) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:223) at com.android.server.SystemServer.run(SystemServer.java:631) at com.android.server.SystemServer.main(SystemServer.java:417) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:925) Change-Id: I98d5f4bad9af7faaea8d5333362d080f41a16c85

Change-Id: I008370cefe9584c86e058b718e2ef79518b95eb6 Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: Anush02198 <Anush.4376@gmail.com>

When request pick gesture sensor, judge that if the current user does not turn on the face unlocking function, the sensor should not be Listening Fixes: 161954958 Test: presubmit Change-Id: I34552315049e07f123403fe693251edb460fef5d Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: Anush02198 <Anush.4376@gmail.com>

This can happen if the fingerprint is validated twice in a row before the view has time to disappear. Make the method synchronized to avoid race conditions of any kind and add an additional try-catch as a safeguard. Change-Id: Ic2b76be1cc0f5217351e39ec24159ca23043ab4f Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: Anush02198 <Anush.4376@gmail.com>

In order to enforce SafetyNet security, Google Play Services is now using hardware attestation for ctsProfile validation in all cases, even when basic attestation is selected. The SafetyNet API response from GMS will report that basic attestation was used, but under the hood, hardware attestation is always used regardless of the reported state. This results in SafetyNet failing to pass due to TrustZone reporting an unlocked bootloader (and a partially invalidated root of trust) in the key attestation result. We can still take advantage of the fact that this usage of hardware attestation is opportunistic - that is, it falls back to basic attestation if key attestation fails to run - and prevent GMS from using key attestation at the framework level. This causes it to gracefully fall back to basic attestation and pass SafetyNet with an unlocked bootloader. Key attestation is still available for other apps, as there are valid uses for it that do not involve SafetyNet. The "not implemented" error code from keymaster is used to simulate the most realistic failure condition to evade detection, i.e. an old device that lacks support for key attestation. Change-Id: I7282ab22b933434bb11037743d46b8a20dad063a Signed-off-by: Joey Huab <joey@evolution-x.org> Signed-off-by: Anush02198 <Anush.4376@gmail.com>

Next-Generation Assistant (NGA) is nice to have for Google Assistant, but it requires proprietary code in SystemUI to work properly. However, newer Pixel devices (Pixel 4 and 5 series) automatically use NGA with no way to opt out, which breaks the assistant entirely on custom ROMs without NGA support. Report the device as a "Pixel 3 XL" to the Google Assistant app during app process specialization to force the usage of the generic assistant UI and mitigate the issue. This is far from ideal, but we just need to make Google Assistant work for now. Screen-off voice match is not broken with this change because the model name still matches that of a valid device with the feature. Signed-off-by: Danny Lin <danny@kdrag0n.dev> Change-Id: I282e7e88cfda50578f016b2ae0bad2e77e9a7238 Spoof build fingerprint for Google Play Services SafetyNet's CTS profile attestation checks whether Build.FINGERPRINT matches that of the device's stock OS, which has passed CTS testing. Spoof the fingerprint for Google Play Services to help pass SafetyNet. We used to set the real system build fingerprint to the stock one, but Android relies on each build having a unique fingerprint in order to clear the correct caches and update persistent state for system changes. On devices that no longer receive updates from the OEM, the build fingerprint never changes and Android doesn't account for updates correctly, which causes issues when updating without wiping data. Only spoofing the fingerprint for Google Play Services fixes this issue. Corresponding vendor commit: "Only use stock build fingerprint for Google Play Services" Change-Id: I415b6760ecf4032bd60f886c319d43bc6d63aef6 core: Make build property spoofing more reliable Determining the package name from Zygote's post-fork process name is unreliable for several reasons: - If USAP is enabled, Zygote will fork with the USAP process name, and spoofing will never trigger when the forked process specializes into a specific app. - With the native fork loop backported from AOSP master, Zygote.setAppProcessName() is no longer used for most apps because the forking is handled by native code. Instrumentation#newApplication() is responsible for creating the Application singleton during each app's initialization, so hook it instead for a more reliable and robust trigger. Change-Id: Ic762d8853967bf78db614efaf46166e527cb397a

Do not return to Java mode between consecutive fork operations. This greatly reduces the Zygote overhead, since we no longer need to stop and restart Java daemons. By not switching back to Java mode, and being careful about what memory we touch between forks, we also keep the Zygote heaps much more stable, facilitating page sharing between the zygote and all its children. Under normal operation we should no longer allocate any memory in the zygote between forks. That applies to both the Java and C++ heap. This makes the zygote behave much more like the mental model many of us had assumed: It has nearly constant memory contents, which are copy-on-right cloned at each fork. This does not apply to the initial system server and webzygote forks, that are currently still handled differently. This includes 1. Add ZygoteCommandBuffer, and switch the argument parsing code to use it. This slightly reduces allocation and enables (3). 2. Support process specialization in the child, even when the arguments are already know, Leverages existing Usap code. 3. Add support for forking multiple child processes directly to the ZygoteCommandBuffer data structure. This directly uses the buffer internals, and avoids returning to Java so long as it can handle the zygote commands it sees. FUNCTIONALITY CHANGE: We now limit the total size of the zygote command, rather than the number of arguments. Initial performance observations: [ These are not perfect, since I'm comparing to numbers before I started. There may have been other moving parts, but they should be minor. ] System-server-observed launch latency: [Not the best metric, but easy to measure. In particular, this does not represent a significant reduction in application launch time.] Based on measuring the last 10 launches in a lightly used cf AOSP instance, the system server latency from requesting an app launch to response with the pid (which does not require the child to execute anything) went from an average of about 10.7(25) msecs to 6.8(9) and 7.9(16) in two tries with the CL. (The parenthetical numbers are maxima from among the 10; the variance appears to have decreased appreciably.) Dirty pages: The number of private dirty pages in the zygote itself appears to have decreased from about 4000 to about 2200. The number of dalvik-main private dirty pages went from about 1500 to nearly zero. Initially ART benchmarking service claim -1.88% in PSS. But this is not consistently repeatable. Drive-by fix: Call setAllowNetworkingForProcess on usap / native loop path. Bug: 159631815 Bug: 174211442 Test: Boots AOSP Change-Id: I90d2e381bada1b6c9857666d5e87372b6a4c1a70

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Uh oh!

Commits on May 9, 2021

This comparison is taking too long to generate.

Uh oh!