A snippet of code found buried in the backend of Android 8.0 Oreo by XDA Developers seems to suggest that Android Oreo may eventually allow OEMs to add secondary functionality to hardware buttons in the near future. To be fair, advanced users have already been playing around with the concept using various methods and workarounds for a while already. However, those workarounds would ordinarily require accessibility features to be enabled and for the screen to be turned on. That can be a serious drain on resources and performance. However, the new code points to a system-level implementation tied directly to permissions.
As of this writing, the code only exists in a commit which defines a “long press listener” that extends the functionality of the hardware-based volume buttons. For those who aren’t already well-versed in the lingo, a listener is effectively a trigger that tells the device to “listen” for a specific interaction to happen or for some other code to run. In this case, the program watches for a hardware key to be pressed and then measures the length of time it is held down for. If the time meets requirements set by the program, another piece of code will run. One benefit, which is listed at the source, is that if the listener in question were to be implemented, users could finally use the volume keys to control music or other first and third party apps – even while the device’s screen is turned off and without necessarily requiring accessibility features to be turned on. That would effectively allow manufacturers to work in functionality similar to HTC’s Edge Sense using only a device’s hardware buttons.
The only drawback is that the commit itself, as the listener and permissions are currently defined, would only be accessible via root permissions – namely the “android.permission.SET_VOLUME_KEY_LONG_PRESS_LISTENER ” permissions. That means that either Google or manufacturers would need to take advantage of the feature in their system level applications for users to see any benefit from the change without, at a minimum, rooting their device and making changes to the functionality through Android’s ADB’s command line console. Manufacturers themselves could also most likely open the feature up for more user-driven customizations if the concept is put into place in a future Android update. Unfortunately, it is just as likely that the code will never see inclusion on the user-side of the Android platform since commits don’t necessarily equate to the eventual release of new features. Bearing that in mind, it may be best to take the news with a grain of salt.