这里列出的许多答案都有内在的问题:

Checking for test-keys is correlated with root access but doesn't necessarily guarantee it "PATH" directories should be derived from the actual "PATH" environment variable instead of being hard coded The existence of the "su" executable doesn't necessarily mean the device has been rooted The "which" executable may or may not be installed, and you should let the system resolve its path if possible Just because the SuperUser app is installed on the device does not mean the device has root access yet

Stericson的RootTools库似乎可以更合理地检查root。它还有很多额外的工具和实用程序，所以我强烈推荐它。然而，并没有解释它是如何专门检查根目录的，而且它可能比大多数应用程序真正需要的要重一些。

我已经创建了几个基于RootTools库的实用程序方法。如果你只是想检查“su”可执行文件是否在设备上，你可以使用以下方法:

public static boolean isRootAvailable(){
    for(String pathDir : System.getenv("PATH").split(":")){
        if(new File(pathDir, "su").exists()) {
            return true;
        }
    }
    return false;
}

这个方法简单地遍历“PATH”环境变量中列出的目录，并检查其中是否存在“su”文件。

为了真正检查root访问权限，必须实际运行“su”命令。如果安装了一个像SuperUser这样的应用程序，那么在这一点上它可能会要求root访问，或者如果它已经被授予/拒绝，吐司可能会显示是否授予/拒绝访问。一个很好的命令是“id”，这样您可以验证用户id实际上是0(根)。

下面是一个示例方法来确定是否授予了根访问权:

public static boolean isRootGiven(){
    if (isRootAvailable()) {
        Process process = null;
        try {
            process = Runtime.getRuntime().exec(new String[]{"su", "-c", "id"});
            BufferedReader in = new BufferedReader(new InputStreamReader(process.getInputStream()));
            String output = in.readLine();
            if (output != null && output.toLowerCase().contains("uid=0"))
                return true;
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (process != null)
                process.destroy();
        }
    }

    return false;
}

实际测试运行"su"命令是很重要的，因为一些模拟器已经预安装了"su"可执行文件，但只允许某些用户像adb shell一样访问它。

在尝试运行“su”可执行文件之前检查它的存在也是很重要的，因为android已经知道不会正确地处理试图运行缺失命令的进程。随着时间的推移，这些幽灵进程会消耗大量内存。

更新2017

你现在可以用谷歌Safetynet API做到这一点。SafetyNet API提供了认证API，它可以帮助您评估应用程序运行的Android环境的安全性和兼容性。

这种认证可以帮助确定特定设备是否被篡改或修改过。

认证API返回如下所示的JWS响应

{
  "nonce": "R2Rra24fVm5xa2Mg",
  "timestampMs": 9860437986543,
  "apkPackageName": "com.package.name.of.requesting.app",
  "apkCertificateDigestSha256": ["base64 encoded, SHA-256 hash of the
                                  certificate used to sign requesting app"],
  "apkDigestSha256": "base64 encoded, SHA-256 hash of the app's APK",
  "ctsProfileMatch": true,
  "basicIntegrity": true,
}

解析此响应可以帮助您确定设备是否已扎根

根设备似乎导致ctsProfileMatch=false。

您可以在客户端执行此操作，但建议在服务器端解析响应。 一个基本的客户端服务器架构与安全网API将看起来像这样

RootTools库提供了简单的方法来检查根:

RootTools.isRootAvailable()

参考

使用谷歌SafetyNet认证API，您可以轻松检查您的设备是否已根:

Add dependency in build.gradle(:app) implementation 'com.google.android.gms:play-services-safetynet:17.0.0' Get Api key and enable Android Device Verification API using link public static void sendSafetyNetRequest(Activity context) { if(GoogleApiAvailability.getInstance().isGooglePlayServicesAvailable(context, 13000000) == ConnectionResult.SUCCESS) { Log.e(TAG, "The SafetyNet Attestation API is available"); // TODO(developer): Change the nonce generation to include your own, used once value, // ideally from your remote server. String nonceData = "Safety Net Sample: " + System.currentTimeMillis(); ByteArrayOutputStream byteStream = new ByteArrayOutputStream(); Random mRandom = new SecureRandom(); byte[] bytes = new byte[24]; mRandom.nextBytes(bytes); try { byteStream.write(bytes); byteStream.write(nonceData.getBytes()); } catch (IOException e) { e.printStackTrace(); } byte[] nonce = byteStream.toByteArray(); SafetyNetClient client = SafetyNet.getClient(context); Task<SafetyNetApi.AttestationResponse> task = client.attest(nonce, API_KEY_FROM_STEP_2_LINK); task.addOnSuccessListener(context, attestationResponse -> { /* TODO(developer): Forward this result to your server together with the nonce for verification. You can also parse the JwsResult locally to confirm that the API returned a response by checking for an 'error' field first and before retrying the request with an exponential backoff. NOTE: Do NOT rely on a local, client-side only check for security, you must verify the response on a remote server! */ String jwsResult = attestationResponse.getJwsResult(); Log.e(TAG, "Success! SafetyNet result:\n" + jwsResult + "\n"); if (jwsResult == null) { Log.e(TAG, "jwsResult Null"); } final String[] jwtParts = jwsResult.split("\\."); if (jwtParts.length == 3) { String decodedPayload = new String(Base64.decode(jwtParts[1], Base64.DEFAULT)); Log.e(TAG, "decodedPayload : " + decodedPayload); } }); task.addOnFailureListener(context, e -> { // An error occurred while communicating with the service. String mResult = null; if (e instanceof ApiException) { // An error with the Google Play Services API contains some additional details. ApiException apiException = (ApiException) e; Util.showLog(TAG, "Error: " + CommonStatusCodes.getStatusCodeString(apiException.getStatusCode()) + ": " + apiException.getStatusMessage()); } else { // A different, unknown type of error occurred. Log.e(TAG, "ERROR! " + e.getMessage()); } }); } else { Log.e(TAG, "Prompt user to update Google Play services."; } } ` Check your logs for decodedPayload if ctsProfileMatch and basicIntegrity both are false it means your device is rooted . The Attestation API returns a JWS response which looks like:

{"nonce": "6pLrr9zWyl6TNzj+kpbR4LZcfPY3U2FmZXR5IE5ldCBTYW1wbGU6IDE2MTQ2NzkwMTIzNjc="， " timestamms ": 9860437986543， "apkPackageName": "你的包名将显示在这里"，"ctsProfileMatch": true， "apkDigestSha256": ["base64编码，用于签名请求应用程序的证书的SHA-256哈希值"]，"basicIntegrity": true， "evaluationType": "BASIC"}

欲了解更多信息，请查看此链接。

在我的应用程序中，我通过执行“su”命令检查设备是否根。但是今天我删除了这部分代码。为什么?

因为我的应用程序成了内存杀手。怎么做?让我告诉你我的故事。

There were some complaints that my application was slowing down devices(Of course I thought that can not be true). I tried to figure out why. So I used MAT to get heap dumps and analyze, and everything seemed perfect. But after relaunching my app many times I realized that device is really getting slower and stopping my application didn't make it faster (unless I restart device). I analyzed dump files again while device is very slow. But everything was still perfect for dump file. Then I did what must be done at first. I listed processes.

$ adb shell ps

使震惊;我的应用程序有许多进程(应用程序的进程标签在manifest上)。有些是僵尸，有些不是。

对于一个只有一个Activity并只执行“su”命令的示例应用程序，我意识到在每次启动应用程序时都会创建一个僵尸进程。起初，这些僵尸进程分配0KB，但后来发生了一些事情，僵尸进程与我的应用程序的主进程占用了几乎相同的kb，它们成为了标准进程。

在bugs.sun.com: http://bugs.sun.com/view_bug.do?bug_id=6474073上有一个关于相同问题的错误报告，这解释了如果命令没有找到，将使用exec()方法创建僵尸。但我仍然不明白它们为什么以及如何成为标准流程并保持重要的kb。(这并不是一直都在发生)

你可以尝试如果你想下面的代码示例;

String commandToExecute = "su";
executeShellCommand(commandToExecute);

简单的命令执行方法;

private boolean executeShellCommand(String command){
    Process process = null;            
    try{
        process = Runtime.getRuntime().exec(command);
        return true;
    } catch (Exception e) {
        return false;
    } finally{
        if(process != null){
            try{
                process.destroy();
            }catch (Exception e) {
            }
        }
    }
}

总结:总结;我没有建议你确定设备是否扎根。但如果我是你，我不会使用Runtime.getRuntime().exec()。

顺便说一下;RootTools.isRootAvailable()也会引起同样的问题。

截至2021年(今天)，似乎没有任何可靠的方法或方法来检测根目录，特别是在启用了MagiskHide等强大的隐藏工具的情况下。这里的大多数答案都不再相关，所以不要在生产中使用它。依靠可靠的检查，如SafetyNet，而不是额外的英里检测根，我建议在两个运行时保护你的应用程序，如防止调试器/检测，并确保使用混淆。