如何从shell中识别Android设备的分区？

Question

如何从shell中识别Android设备的分区？

22

我正在尝试查找哪个分区用于什么，例如/boot，/recovery，/system，从adb shell。对于当前已挂载的分区（使用mount或df命令，参见例如如何识别分区名称），这很简单，但是当涉及到当前未挂载的分区（例如在“用户模式”下引导时的/recovery）时，这似乎很棘手。

有一个XDA上的教程，但它对我尝试过的任何设备都没有起作用：

cat /proc/mtd：此为空或不存在
cat /proc/emmc：此为空或不存在
cat /proc/dumchar_info：不存在（MTK / MediaTek）
ls -al /dev/block/platform/*/by-name：要么不存在，要么没有所需的详细信息
parted在/dev/block/mmcblk1上产生了Error: Can't have a partition outside the disk!（而对于/dev/block/mmcblk0，则简单地缺少“name”列）。

所以我迷失了方向。我知道有像DiskInfo这样的应用程序可以显示这些详细信息，因此它们必须存储在设备上的某个位置。但是，在我的情况下，修改设备（通过安装应用程序）不是一个选项。

因此，基本上我的问题就是： Android设备上的此信息存储在哪里？ 如果可能，最好使用通用方法。如果不行，则可以使用多种尝试方法（例如if..elseif..fi）。

背景：一个示例用途将是“我只想检索/boot分区”（通过dd获取其图像）。先抓取所有分区，然后再评估是不行的 - 太耗时间，产生的数据太多;) - 这已经描述了意图：编写一个小工具来检索特定的磁盘映像。

- Izzy

你需要的信息是什么（大小、位置、挂载），在/proc/mounts中没有找到？ - jan

@jan 如所述，每个分区的“用途”。例如，从mount或者你所说的/proc/mounts中得出，/dev/block/mmcblk1p21持有system分区。但请注意，就像mount命令本身一样，它只保留当前挂载的分区。但我也需要那些当前未挂载的分区（例如正常启动时的recovery）。大小相对不太重要，对我来说最重要的是识别。 - Izzy

我只需执行 ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name 命令，即可获取指向实际设备的分区名称列表。 - jan

1

@jan 同意 - 如果可能的话（请参见我的问题：/dev/block/platform/*/by-name：某些设备上不存在）。 - Izzy

@Andreyua 你看到了 从 shell 中 的部分，以及 修改设备（通过安装应用程序）不是一个选项 的限制吗？ - Izzy

2个回答

1

您可以通过https://dev59.com/B1nUa4cB1Zd3GeqPb5qq#15639867获取Linux上已挂载分区的信息，但如果/dev/block/platform/**/by-name没有它，我认为Linux内核不知道boot和recovery分区。

因此，您可以使用当前挂载的信息来猜测哪个分区是boot或recovery，或者在/dev/block/*中未挂载的其他分区。

实际上，fastboot只发送您想要刷写的分区名称。我想这意味着只有fastboot引导加载程序知道这些信息。

https://github.com/android/platform_system_core/blob/8163104b3feb575a321b194a70ecb9873a70b29d/fastboot/fastboot_protocol.txt

- Kazuki Sakamoto

谢谢Kazuki - 但是对于20多个分区（当前连接的设备上有26个，从mmcblk1p1到mmcblk1p26），猜测是太容易出错了，其中只有3或4个被挂载（在提到的设备上有3个）- 特别是“通过脚本自动猜测”。即使跳过所有2048块及以下的分区，该设备上仍有10个分区，减去3个已挂载的分区，还剩下7个要猜测。fastboot可以自己找出来，这证明信息必须能够自动获取（除非它被硬编码到设备上的其对应部分中）。 - Izzy

1

fastboot是引导加载程序的一部分，它与Linux系统分离，因此我认为您无法通过与Linux内核上的adbd通信的adb shell获取信息。 - Kazuki Sakamoto

这是一个很有道理的观点。我认为fastboot应该被单独看待；当以fastboot模式启动时，“正常系统”根本没有“启动”。因此，从我的最后一条评论中删除那个“证据”；但是，由于应用程序可以找到详细信息（请参见我的问题中的示例），它仍然必须以某种方式获得。 - Izzy

DiskInfo在每个设备上都是正确的吗？如果是这样，您可以使用root权限进行strace或其他操作来检查应用程序获取信息的方式。但我怀疑这一点。另请参阅http://www.all-things-android.com/content/review-android-partition-layout - Kazuki Sakamoto

我无法在“每个设备”上测试它-这只是我听说的。而且，我昨天已经尝试了给定的链接。无法进一步到达“Cloudflare DDos检查”，永远无法到达真正的页面。啊，刚刚通过Google缓存得到了它：基本上是我已经尝试过的。除了blkid，不幸的是该设备上没有此命令:( 无论如何，感谢您的指引！ - Izzy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Izzy · Accepted Answer

由于似乎没有“独特的方法”来实现这一点，因此我开始从各个方面结合想法，将它们组合成一个脚本（或者说是“脚本库”），以便按顺序进行检查（直到找到一个好的命中点），并将其集成到我的“设备文档工具”中，名称为Adebar。有兴趣的人可以在lib/partitions.lib文件中找到它。由于Adebar是开源的（GPLv2），请随意复制和使用它-或者分叉该项目并改进它。

完整的解决方案在此处发布会有点长（如上所述，您可以在Github上获取它），但由于SE政策要求至少在帖子中包含一般部分，因此以下是它的作用：

不同的来源提供不同的详细信息，因此它首先尝试“最佳”的那些-然后向下递归，直到至少找到了一些东西。

/proc/dumchar_info提供的详细信息最多，因此首先尝试。快乐的MTK用户将获得此类信息。
/proc/mtd是第二个最佳来源。
/proc/emmc应该几乎与先前的候选者一样多，但使用起来有点棘手
/dev/block/platform/*/by-name，与之交叉检查...
/proc/partitions交叉检查/proc/mounts至少给出了挂载的分区。

因此，我构建的脚本基本上按照这个顺序遍历源代码，停止时收集详细信息（例如，如果找到了/proc/dumchar_info，则没有必要解析所有其他信息）。它们都放在单独的函数中，使用完全相同的结构返回数据，甚至可以合并所有结果。

如果有人能想出更好的解决方案，我当然随时欢迎想法：）