Can somebody get this app running with Magisk/Apatch?

We understand the frustration that comes with encountering application detection mechanisms on a rooted Android device. The specific challenge you are facing with the “AOK Mein Leben” application, particularly its ability to detect custom ROM environments like LineageOS, represents one of the most complex categories of root detection currently present in the Android ecosystem. While standard banking apps or streaming services typically target the su binary or unlocked bootloaders, applications designed for sensitive institutional use—such as health portals or government services—often implement far more aggressive integrity checks.

In this comprehensive guide, we will dissect the technical hurdles presented by the “AOK Mein Leben” app, analyze why standard Magisk and Apatch configurations are likely failing to bypass the red warning sign, and explore the specific limitations regarding Non-GKI devices and Android 16 kernels. Our objective is to provide a detailed technical roadmap that addresses the nuances of custom ROM detection, Zygisk integration, and the critical role of Play Integrity API (PIA) spoofing.

Understanding the “AOK Mein Leben” Detection Architecture

To solve the problem of getting this specific application running, we must first understand what it is looking for. The application identified by the package name de.aok.digen is not merely checking for the presence of a root binary; it is performing a comprehensive environmental attestation.

The Custom ROM Detection Mechanism

You noted that the app detects your LineageOS installation. This is a significant hurdle because LineageOS, by its open-source nature, leaves specific fingerprints in the build properties that are distinct from stock firmware. Common detection vectors include:

• Build Fingerprints: The app likely queries ro.build.fingerprint. If this does not match the specific stock ROM of your device (e.g., a OnePlus stock fingerprint), the app flags the environment.
• Build Tags: LineageOS typically includes release-keys or test-keys in ro.build.tags. Many custom ROMs inadvertently expose ro.debuggable=1.
• System Properties: Applications may check ro.product.name, ro.product.device, and ro.build.display.id against a whitelist of known stock configurations.

We must recognize that standard Magisk module scripts often focus on hiding the su binary but fail to rewrite these build properties comprehensively. If the app checks these properties and finds a mismatch, it will trigger the red warning sign regardless of how well root is hidden.

Play Integrity API (PIA) vs. SafetyNet

The shift from SafetyNet to Play Integrity API has changed the landscape of root hiding. You mentioned passing BASIC + DEVICE integrity. In the context of Android 16 and modern Play Integrity responses, passing these levels is often insufficient for high-security applications.

• BASIC Integrity: Checks if the device is passing basic integrity checks. This is usually the easiest to pass.
• DEVICE Integrity: Checks if the device is a genuine Android device running unmodified software. This is harder.
• STRONG Integrity: This is the highest tier, verifying that the device is running a specific, unmodified boot image signed by the OEM.

The “AOK Mein Leben” app, handling sensitive health data, may be checking for STRONG integrity, or it may be using a proprietary SDK that looks deeper than the standard Play Integrity API response. If your device is failing the “DEVICE” integrity check due to the custom ROM, the app will not proceed.

Why Magisk and Apatch Are Failing

Magisk and Apatch are powerful tools, but they operate within specific constraints, especially regarding system modification detection.

Zygisk and Module Interaction

You mentioned using “different zygisk variants + HMA + PIF.”

• Zygisk: This is Magisk’s framework for modifying the Zygote process. While essential for many modules, it can be detected by apps that check for loaded libraries or specific function hooks.
• Hide My Applist (HMA): HMA is excellent for hiding other apps from the target app, but it does not inherently spoof system properties or Play Integrity responses. If the app detects the custom ROM via ro.build.* properties before checking for installed apps, HMA will not help.
• Play Integrity Fix (PIF): This module is critical for spoofing the device fingerprint to pass Play Integrity. However, on Android 16, the PIF module must be configured with a valid fingerprint from a stock device that matches your Android version and security patch level. If you are using a generic fingerprint or one from an older Android version, the app may detect the discrepancy.

The Limitation of Apatch

Apatch is a newer alternative to Magisk that patches the kernel directly. While it offers a different approach to systemless modification, it shares similar detection vectors. If Apatch does not have a robust mechanism to spoof the ro.build.fingerprint and other critical system properties, it will fail against apps that perform property checks. Furthermore, Apatch’s compatibility with specific kernels (especially Non-GKI) is still maturing compared to Magisk.

The Non-GKI Kernel and Android 16 Challenge

Your specific hardware situation—the OnePlus 7 Pro running a Non-GKI kernel on Android 16—presents a massive technical bottleneck.

What is GKI (Generic Kernel Image)?

Google introduced GKI with Android 12 to unify the kernel interface. Kernels before Android 12 (like the one in the OnePlus 7 Pro) are Non-GKI. This means the kernel is tightly coupled with vendor modules and lacks the standardized interfaces that modern root solutions rely on for seamless integration.

The Android 16 Problem

Android 16 is a bleeding-edge version of the OS. Most custom kernel developers have not yet ported kernels for older, Non-GKI devices to Android 16.

• Kernel Source Incompatibility: The source code for the OnePlus 7 Pro kernel is based on Android 11/12. Forcing it to run on Android 16 requires significant backporting of drivers and security patches.
• Lack of Prebuilt Kernels: As you noted, there are no prebuilt custom kernels for A16 on your device. This means you cannot easily flash a kernel that supports KSU (KernelSU) or specific Magisk kernel features.

Why KernelSU (KSU) Might Be the Missing Piece

You expressed curiosity about whether KSU is required. KernelSU operates at the kernel level, granting it root access without relying on the traditional su binary or Zygote modification. This makes it significantly harder to detect for apps that only look for user-space root binaries.

• However, KSU requires a kernel patch. Without a custom kernel for Android 16 on your Non-GKI device, you cannot install KernelSU.
• Even if you could install KSU, it does not automatically solve the custom ROM detection. You would still need to spoof system properties to make LineageOS appear as the stock OxygenOS to the “AOK Mein Leben” app.

Strategic Solutions for LineageOS and AOK App

Since KernelSU is currently out of reach due to the lack of a compatible kernel for Android 16, we must optimize your existing Magisk/Apatch setup to address the specific detection vectors of the “AOK Mein Leben” app.

1. Advanced Play Integrity Fix Configuration

Passing “BASIC + DEVICE” is likely not enough. We need to target “STRONG” or at least ensure the “DEVICE” response is rock solid.

• Fingerprint Selection: You must use a PIF module that selects a fingerprint from a stock device running the same Android version and security patch level as your LineageOS build. Do not use generic fingerprints.
• Modulus Verification: Some advanced PIF forks (like the “Play Integrity Fix” by chiteroman) handle the hardware-backed key attestation better. Ensure you are using the latest version compatible with Android 16.
• Tricky Store Integration: To pass the “STRONG” integrity check, the Tricky Store module is often required. It generates valid hardware-backed keys that satisfy Google’s attestation servers. However, Tricky Store requires a valid key from a stock device, which can be difficult to obtain for specific models.

2. System Property Spoofing (The “Fabricate” Approach)

Because the app likely detects LineageOS via ro.build.* properties, we must override them without triggering SafetyNet/Play Integrity warnings.

• Systemless Props Config: We recommend using the “Systemless Props Config” module. This module allows you to fake device fingerprints and build properties systemlessly.
• The Strategy: You need to spoof your device to a stock OnePlus 7 Pro OxygenOS build. However, you must be careful. If you spoof a fingerprint that is too old (e.g., Android 10), the Play Integrity API might reject it because it doesn’t match your active security patch level on Android 16.
• Dynamic Props: You can create a custom profile in Systemless Props Config that specifically targets the “AOK Mein Leben” app. By using the magiskhide or zygisk denylist feature, you can apply specific property overrides only when that app is launched, while leaving the rest of the system intact.

3. Shamiko and Zygisk Configuration

You are using Magisk. To maximize stealth:

• Shamiko Module: If you are using Magisk Delta or the official Magisk with Zygisk enabled, the Shamiko module is superior to older hide methods. It provides “Zygisk DenyList” functionality that hides the Magisk environment more effectively than the standard denylist.
• Enforce DenyList: Ensure “Enforce DenyList” is active in Magisk settings. You should add “AOK Mein Leben” to the DenyList.
• Process Hiding: When an app is on the DenyList, Zygisk unmounts the Magisk environment from that app’s process. This is crucial for hiding the su binary and Magisk Manager from the app.

4. HMA (Hide My Applist) Configuration

Since you are already using HMA, we need to ensure it is configured for maximum efficacy against detection.

• Template System: HMA works by injecting a fake list of installed apps or blocking the app’s request to list others. For “AOK Mein Leben,” the app might be checking for other root-related apps (like Termux, Magisk Manager, or banking apps) to determine if the environment is hostile.
• Expert Mode: Enable Expert Mode in HMA. You can configure it to block specific intents and queries. Specifically, you should block the app from querying the package manager for specific system packages that might reveal the custom ROM status.
• Scope: Apply the HMA profile strictly to the “AOK Mein Leben” app. Do not apply it globally, as this can cause system instability.

The Non-GKI Limitation: A Hard Constraint

We must be realistic about the constraints imposed by your device’s kernel. The OnePlus 7 Pro (guacamole) runs on the msm8998 chipset, which is a Non-GKI device.

• No Kernel Patches: Without a custom kernel for Android 16, you cannot patch the kernel to support KernelSU or Magisk’s kernel-level hiding features (like resetprop at the kernel level).
• Vendor Partition: On Non-GKI devices, the vendor partition is older and may not support the latest security features required by Android 16. This can cause Play Integrity failures because the device’s hardware attestation (TEE) might report a mismatch between the new OS and the old vendor implementation.

Conclusion on KSU: It is currently not possible to get KernelSU running on Android 16 for the OnePlus 7 Pro without a custom kernel. Therefore, you must rely on Magisk and Apatch user-space hiding techniques.

Step-by-Step Troubleshooting Guide

To attempt to bypass the red warning sign, follow this structured approach using your existing Magisk setup.

Step 1: Clean Environment

1. Uninstall all conflicting modules.
2. Keep only: Magisk (or Apatch), Zygisk enabled, Shamiko (if using Magisk), Play Integrity Fix, and Systemless Props Config.
3. Disable HMA temporarily to isolate the issue.

Step 2: Configure Play Integrity Fix

1. Open your PIF module configuration.
2. Select a fingerprint for a OnePlus 7 Pro running Android 11 or 12 (the last official versions for this device).
3. Since you are on Android 16, you must ensure the fingerprint matches the security patch level as closely as possible, or use a fingerprint from a device that has a valid attestation chain for high Android versions (e.g., a Pixel device).
4. Run the “Check Integrity” task in the PIF module to see the exact response.

Step 3: Spoof LineageOS Properties

1. Open “Systemless Props Config” via terminal or Magisk app.
2. Select “Edit device fingerprint” and choose a stock OnePlus 7 Pro fingerprint (e.g., oneplus/oneplus7pro/oneplus7pro:11/RP1A.200720.011/2106212018:user/release-keys).
3. Reboot.
4. Check if the app still detects the custom ROM. If it does, you may need to spoof additional properties like ro.product.model and ro.product.brand.

Step 4: Configure HMA for AOK App

1. Re-enable HMA.
2. Create a new profile for “AOK Mein Leben.”
3. In the “Hide App” section, add Magisk Manager, Termux, and any other root-related apps.
4. In the “Expert” section, try to block the app’s ability to read /system/build.prop or access the PackageManager service.
5. Enable “Sysconfig Spoof” if available.

Step 5: Testing and Iteration

1. Clear the data and cache of the “AOK Mein Leben” app.
2. Launch the app.
3. If you still see the red warning, the app is likely performing a hardware-backed attestation that fails because your device is running an unofficial OS (LineageOS) on a Non-GKI kernel.
4. At this stage, without KernelSU or a stock ROM, the app may be technically impossible to run.

Why the Red Warning Persists

The red warning sign in “AOK Mein Leben” indicates a failure in the app’s trust mechanism. Given that you have tried Magisk & Apatch with Zygisk variants, HMA, and PIF, and you are passing BASIC/DEVICE integrity, the most likely culprit is the Strong Integrity or Custom ROM check.

The app’s SDK likely checks the ro.boot.verifiedbootstate or ro.boot.verification flags. On a custom ROM like LineageOS, these are often set to “orange” (unlocked) or reflect a custom state. Standard Magisk modules cannot alter these bootloader flags because they are read-only partitions (boot/recovery) that Magisk does not modify directly (it only patches the boot image to load itself).

Furthermore, the Play Integrity API’s “DEVICE” integrity check on Android 16 is stricter. If the app is checking the “DEVICE” integrity and finding that it is not “GREEN” (meaning the device is unmodified), it will trigger the warning. Since you are using a custom kernel (or the stock kernel with a custom OS), the TEE (Trusted Execution Environment) might be reporting that the OS is not official.

Final Verdict

Based on your device specifications (OnePlus 7 Pro, Non-GKI, Android 16, LineageOS) and the aggressive detection of the “AOK Mein Leben” app, the situation is difficult but not necessarily impossible.

Is it possible without KSU? Yes, it is theoretically possible, but it requires a perfect spoof of the device identity. You are fighting two battles:

1. Root Hiding: Magisk + Shamiko + HMA handles this.
2. System Identity Spoofing: This is where the battle is lost. You must convince the app that you are running a stock OxygenOS device with a locked bootloader.

If the app uses the Google Play Integrity API’s “DEVICE” or “STRONG” verdict to determine if the OS is official, and if your custom ROM modifies the boot image signature (which it does), then Google’s servers will report a failure. Magisk cannot fake the boot image signature to Google’s servers; it can only hide the fact that the signature was modified from the local app.

Recommendation: Focus heavily on the Play Integrity Fix and Systemless Props Config. Try using a fingerprint from a device that has a valid “STRONG” integrity verdict (like a Pixel 8 or 9 running Android 16, if available), rather than a OnePlus 7 Pro fingerprint. While this is “device spoofing,” it is often necessary to bypass these strict institutional checks. However, be aware that this may break other apps that require exact device matching.

If the app continues to detect the custom ROM despite these efforts, it is likely utilizing a proprietary, non-standard detection method that relies on hardware-level inconsistencies that cannot be patched without KernelSU or a stock ROM restore.