Biometric authentication may not be as secure as pins or passwords, but its convenience is a big selling point for many consumers. The extremely quick fingerprint scanner on the OnePlus flagships has been praised almost universally, but lately companies have been gravitating towards facial recognition technology as an alternative. For instance, there’s the OnePlus 5T and the Honor 7X with their respective takes on a Face Unlock feature. Samsung phones also have facial recognition for unlocking their devices, but the biometric authentication technology the company is most proud of is its iris scanner. Now, it appears that iris scanners may be coming to more Android phones in the future, as official support for it is being added to Android.
Iris Scanners on Existing Android Hardware
The first mainstream Android smartphone with an iris scanner was the ill-fated Samsung Galaxy Note 7. That technology later made its way over to the Samsung Galaxy S8/S8+ and the Galaxy Note 8. We also know it will launch with the Samsung Galaxy S9/S9+ and it will offer incremental improvements in hardware, but by combining it with facial recognition, the overall experience should improve. (There’s also a possibility an iris scanner may make its way over to an unannounced Samsung Galaxy phone, but that’s up in the air as of now.)
For those of us without a Samsung Galaxy flagship, there aren’t very many options when it comes to a smartphone with an iris scanner. In fact, there’s actually only a single option, and the phone isn’t even yet available for sale. An obscure smartphone called the BitVault that is aimed at cryptocurrency enthusiasts.
BitVault: the self-proclaimed “World’s First Blockchain Phone”. Source: Swiss Bank In Your Pocket.
This smartphone, along with an unannounced smartphone from a Japanese smartphone OEM, are the only non-Samsung Galaxy devices that I’m aware of that offer iris scanning. The chip that powers these phones’ iris scanners is the FPC ActiveIRIS by Fingerprints.
You may have never heard of this company, but you have most likely used a smartphone that incorporates their technology. Some of the smartphones that use fingerprint scanners from FPC include the Google Pixel, the Honor 8, and the Huawei Mate 9 Pro. Their fingerprint sensors are found on many other devices, including several from Xiaomi, so it’s safe to say that FPC is one of the leading vendors in selling the biometric authentication technology found in smartphones.
FPC Fingerprint Scanners on the Home Button, Rear, and Side of the Device. Source: FPC.
So why is this company important? It’s because several of their engineers have been working on incorporating native support for biometric iris scanners in Android. There are several commits here, all of which should be looked at together to get a good picture of what’s going on.
Iris Scanners in a Future Version of Android
Let’s start with the most important commit: the Biometrics Iris HAL interface.
The inclusion of a HAL interface will standardize how the Android framework will communicate with Iris scanners. This means that products from multiple vendors, not just from FPC themselves, will be able to function on Android. Most importantly, this also opens up the ability for AOSP-based ROMs to function generically with Iris scanning hardware. For instance, the Project Treble GSIs rely on this in order for basic fingerprint scanner functionality to work out of the box, so without this, the new Exynos Samsung Galaxy S9 and Galaxy S9+ will be unable to use the Iris scanner on an AOSP ROM.
The SELinux policies for the Iris scanners are wholly uninteresting for end users, but they’re there if you want to take a look at it. The inclusion of the base Iris feature in Android will allow for apps to detect if the device has an Iris scanner in place. Finally, the inclusion of the Iris framework is what will actually allow for third-party apps to utilize the Iris scanner for authentication in the future. Here are the relevant strings:
Iris Scanner in Framework
<string name="permlab_manageIris">manage iris hardware</string> <!-- Description of an application permission, listed so the user can choose whether they want to allow the application to do this. --> <string name="permdesc_manageIris">Allows the app to invoke methods to add and delete iris templates for use.</string> <!-- Title of an application permission, listed so the user can choose whether they want to allow the application to do this. --> <string name="permlab_useIris">use iris hardware</string> <!-- Description of an application permission, listed so the user can choose whether they want to allow the application to do this. --> <string name="permdesc_useIris">Allows the app to use iris hardware for authentication</string> <!-- Message shown during iris acquisision when the iris cannot be recognized --> <string name="iris_acquired_insufficient">Couldn\'t process iris. Please try again.</string> <!-- Message shown during iris acquisision when the iris image is too bright --> <string name="iris_acquired_too_bright">Iris is too bright. Please try in low light.</string> <!-- Message shown during iris acquisision when the iris image is too dark --> <string name="iris_acquired_too_dark">Iris is too dark. Please uncover light source.</string> <!-- Message shown during iris acquisision when the user is too close --> <string name="iris_acquired_too_close">Move further.</string> <!-- Message shown during iris acquisision when the user is too far --> <string name="iris_acquired_too_far">Move closer.</string> <!-- Message shown during iris acquisision when the user eyes closed--> <string name="iris_acquired_eyes_closed">Open eyes.</string> <!-- Message shown during iris acquisision when the user eyes partially obscured--> <string name="iris_acquired_eyes_partially_obscured">Open eyes wider.</string> <!-- Array containing custom messages shown during iris acquisision from vendor. Vendor is expected to add and translate these strings --> <string-array name="iris_acquired_vendor"> </string-array> <!-- Error message shown when the iris hardware can't be accessed --> <string name="iris_error_hw_not_available">Iris hardware not available.</string> <!-- Error message shown when the iris hardware has run out of room for storing iriss --> <string name="iris_error_no_space">Iris can\'t be stored. Please remove an existing iris.</string> <!-- Error message shown when the iris hardware timer has expired and the user needs to restart the operation. --> <string name="iris_error_timeout">Iris time out reached. Try again.</string> <!-- Generic error message shown when the iris operation (e.g. enrollment or authentication) is canceled. Generally not shown to the user--> <string name="iris_error_canceled">Iris operation canceled.</string> <!-- Generic error message shown when the iris operation fails because too many attempts have been made. --> <string name="iris_error_lockout">Too many attempts. Try again later.</string> <!-- Generic error message shown when the iris operation fails because strong authentication is required --> <string name="iris_error_lockout_permanent">Too many attempts. Iris sensor disabled.</string> <!-- Generic error message shown when the iris hardware can't recognize the iris --> <string name="iris_error_unable_to_process">Try again.</string> <!-- Template to be used to name enrolled irises by default. --> <string name="iris_name_template">Iris <xliff:g id="irisId" example="1">%d</xliff:g></string> <!-- Array containing custom error messages from vendor. Vendor is expected to add and translate these strings --> <string-array name="iris_error_vendor"> </string-array> <!-- Content description which should be used for the iris icon. --> <string name="iris_icon_content_description">Iris icon</string> <!-- Title of an application permission, listed so the user can choose whether they want to allow the application to do this. -->
In the Manifest of the Framework, the suggested permission titled “android.permission.USE_IRIS” has a protection level of “normal,” so third-party apps would indeed be able to request the permission and it would be up to the user to grant it.
Lastly, another commit adds support for iris identification in the keyguard. This is what will actually allow the user to scan their iris to dismiss the lock screen. According to the commit, iris authentication only occurs as soon as the screen turns on in order to reduce power consumption. Further, the Iris scanner can be disabled according to the Device Policy Manager if that authority (such as a workplace) deems the iris scanner an insecure method of authentication.
Something interesting going on in all of these commits is how, in many places, references to fingerprints in the Android framework are being genericized to refer to biometrics. This prepares Android for potentially additional methods of biometric authentication in the future, though it’s unclear what that may be.
I won’t bore you with the rest of the implementation details, so I’ll move on to discuss the significance of these commits. What this means for Android is that a future version of Android, likely Android P, will include native support for Iris scanning hardware. I say “likely” because the commits haven’t been merged yet—the changes are very lengthy, and could take a few weeks or even months to pass code review.
It’s very likely that it’ll make it in for Android P, however, and there are even hints of the Iris scanner framework code having P-specific changes in place (such as doing away with storing user-information in /data/system/users and instead re-locating them to a new /data/vendor directory, likely secondary to undisclosed Project Treble requirements).
Further, this does appear to be full support for Iris scanners, though this doesn’t mean that additional features won’t be added by other vendors (in fact, the comments explicitly mention that). The basic implementation is there, though, so we should expect to see future smartphones shipping with biometric Iris scanners. There is no evidence in these commits that the Google Pixel 3 will have such a feature, though, so don’t assume that any particular device will have an Iris scanner because of these changes.
Note: I did reach out to FPC for comment on these changes, but did not receive a response from them by the time of this article’s publication.