Potential ways to resolve compatibility issues for users encountering either:
- their freshly installed banking app aborting at launch
- a previously functional banking app suddenly stopped working
Numerous users encountering such circumstances may find it frustrating and challenging at times. However, for most cases, the common solutions provided below may help resolve some of these banking app’s compatibility issues.
It’s very important to thoroughly read GrapheneOS’s usage guides on Banking apps and Sandboxed Google Play for detailed explanations on topic.
Please be sure to check the banking apps project’s issue tracker for possible per-app updates (example) in user submitted reports.
Enabling native code debugging and/or the per-app exploit protection compatibility mode is the most common solution.
Banking apps obtained from Aurora Store may become problematic, or not work from the start, and could potentially have security risks if using the Anonymous Login feature. Reinstalling from the Play Store using the official (sandboxed) Play Store client has resolved this in these cases.
Enable native code debugging
To improve the app sandbox, GrapheneOS allows users to disable native code debugging for better security. This could possibly interfere with apps debugging their own code to add a barrier to analyzing the app. If you have it disabled and the banking app you’ve installed is not working than you should try enabling it.
To enable native code debugging:
Owner profile →
Enable native code debugging
Enable exploit protection compatibility mode
If your banking app is still not working after enabling native code debugging and aborts after launching then perhaps switching from hardened_malloc to Android’s standard allocator (Scudo) will resolve the issue.
To enable per-app exploit protection compatibility mode:
Enable exploit protection compatibility
Please read our usage guide on bugs uncovered by security features for more details.
AuroraOSS is problematic
Apps can check if they were installed from the Play Store and can choose to refuse to work if they were not installed from the Play Store.
Anonymous Logins may have negative consequence that people may not realize. Their disclaimer addresses this, however, inexperienced users may not read it or even know about it.
Compared to Aurora Stores client, which is just a Play Store front end, the official Play Store client has a much more secure connection to the Play Store servers.
For example - It’s not entirely out of scope for the potential of nefarious operators to reconfigure these shared account for malicious purposes. Although unknown of such cases, technically speaking, it could be realistically possible.
The fact is that such aspects may be explained by straightforward logic, refusing to put your faith with ones lively hood savings in the face of uncertainty is not a risk to take lightly.
Here is some additional information for the end user and possible further action that can be taken to help contribute and support the GrapheneOS project.
SafetyNet replaced by Play Integrity API
Due to the discontinuation of the SafetyNet Attestation API, which has been replaced by the Play Integrity API, some banking apps compatibility issues will not be resolved with the suggested solution(s) above.
Attestation compatibility guide
A detailed guide for app developers on how to support GrapheneOS with the hardware attestation API is provided for users to be able to take further action.
GrapheneOS users are strongly encouraged to share this documentation with app developers enforcing only being able to use the stock OS. Send an email to the developers and leave a review of the app with a link to this information. Share it with other users and create pressure to support GrapheneOS rather than locking users into the stock OS without a valid security reason. GrapheneOS not only upholds the app security model but substantially reinforces it, so it cannot be justified with reasoning based on security, anti-fraud, etc.