我有一个Android 4.1手机(联想820)。经过一些旨在对内部SD ram进行分区的更改(更改后，该电话将不再安装外部SD卡。我对Linux情有独钟，但是在此之前我从未见过Android shell)。
我很想知道以下步骤:
can't read /etc/fstab所示，挂载命令不起作用-如何挂载？ 我的/etc/system/vold.fstab具有:
dev_mount sdcard /storage/sdcard0 emmc@fat /devices/platform/goldfish_mmc.0 /devices/platform/mtk-msdc.0/mmc_host
dev_mount sdcard2 /storage/sdcard1 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-msdc.1/mmc_host
坐骑现在是:
rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/secure type tmpfs (rw,relatime,mode=700)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/emmc@android on /system type ext4 (ro,relatime,nobarrier,noauto_da_alloc,commit=1)
/emmc@usrdata on /data type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@cache on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@protect_f on /protect_f type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
/emmc@protect_s on /protect_s type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
最佳答案
我不敢相信两个月内没有人回复您？哇...好松弛!
好吧，无论如何，我想我应该向您填写一些信息以及提出一些问题。
1)。您是否具有root用户访问权限，或者是否已从发行镜像/固件中拉出系统vold？像Linux的SuperUser权利？
2)。如果您具有 super 用户访问权限/ super 用户权限，您是如何获得的？我的意思是您使用什么方法来获得root访问权限？它是通过某些脚本/二进制文件和已知漏洞利用的吗？还是它是通过 Root过的内核闪烁的？
我问的原因是，root访问权限不只是大多数人都相信的root访问权限。根访问级别不同。例如，您可能以设备用户的身份拥有完全的root用户访问权限，但是有时您想要远程操作系统时，从您最喜欢的Linux发行版的命令行中说出，那么您可能会发现root用户访问权限并不仅限于此是。如果您使用的是漏洞利用程序而不是内核，则可能只有系统级别的根用户访问权限，并且PC的ADB(Android调试桥)将面临各种消息，例如“访问被拒绝”，“无法获得 super 用户特权”。或“adb无法在生产版本中作为root运行”或类似的内容。
发生这种情况的原因是，与某些专门的开发人员通过漏洞利用root进行登录不同，它不会使内核不安全。
我建议您对不安全的内核以及它是否适合您希望达到的目标进行一些阅读。我之所以这样说，是因为在某些内核不安全的设备上并不理想，因为它会触发一些不必要的系统标志(某些制造商称某些标志是永久性的和不可逆的)，并且会被开发人员用来兑现担保或作为提取的手段。为设备提供优质维修服务的钱(不管您是否希望开发人员突破一些发现...是否造成了设备损坏？是哪一种)。我认为您的设备应该没问题...？但是我不确定100％是否会做一些研究。
如果您发现不能运行一个不安全的内核，那就不是世界末日了，只需要更多的工作就可以得到想要的，我将在稍后的示例中详细说明。
您可能应该考虑的下一件事是，当您到达设备中/设备中所需的位置时希望做什么？你有那么想吗？如果是这样的话，您可能会意识到标准的Android控制台/ shell 相当糟糕，并且没有足够的工具来完成您在Linux计算机上就能完成的所有伟大工作；这意味着您将需要一些支持工具，例如“busybox”以及其他一些支持工具，例如，如果您在某些数据库上工作，可能需要sqlite3，则可能需要实际的bash二进制文件来扩展您的 shell 有点。您还不仅要获取这些二进制文件，而且还可能要查看它们在系统上的位置以方便访问，否则，您将不厌其烦地在控制台中键入巨大的长路径以到达设备的某些区域像你的SD卡。您将熟悉使用过Linux的符号链接(symbolic link)，而Android并没有什么不同，只有许多Android系统都将容器之类的环境用于应用程序。在处理此问题时，由于系统已进行安全检查以尝试阻止不需要的第三方入侵，因此可能需要克服一些障碍。这就是让大多数开发人员安全地知道自己(和您的)个人数据受到保护的原因，但是当您是当您并且想要进入设备的这些区域时，需要正确设置工具。大多数Android修补匠使用修改后的恢复镜像(或自定义镜像，与自定义内核概念不太相似)，使他们可以在离线状态下通过大多数简单的zip文件(带有嵌入式教学脚本，二进制文件和二进制文件)来修改系统。 list (研究Android自定义恢复的已签名和未签名的zip-我不会详细介绍它，但这很重要)。本质上，您可以将所有工具打包到一个zip中，然后将组件“闪存”安装到所需的系统区域中，并将相同的文件符号链接(symbolic link)到其他位置。
现在让我们看一些示例，如果我们-假设您具有root访问权限，因为您在设备上使用了漏洞利用程序，但仍具有安全内核，则仍要注意:系统default.prop文件中的安全内核= ro.debugable=0(在启动时生成，未找到或定位)在大多数固件包中)。如果要允许adb具有root访问权限，则需要更改该文件，尤其是我上面提到的行。可能还有其他要求，因此您应该调查设备的需求，例如我目前正在维修的Galaxy Tab较旧，因此使用大容量存储而不是媒体传输协议(protocol)，因此我需要告诉adb与设备连接时保持连接打开且稳定(而不是超时和断开连接)；这恰好也是通过default.prop文件来完成的。
当您要更改此文件时会遇到困难。大多数人对内核和ramdisk进行反编译，然后直接对其进行编辑，重新编译，然后将其重新刷新到设备，主要是因为adb目前显然没有root访问权限。您可以像这样从系统中提取文件:
adb pull default.prop default.prop
(也就是说，如果您的PC发行版环境路径上有adb)
这将带给您平直，唯一的问题是，当您想要在更改后将其放回原处时，可能会非常困难。有关各种解决方案的信息，我听到了很多将其推送到SDcard/emmc/storage/sdcard0/default.prop或/tmp/default.prop的操作，然后要求您使用终端仿真器，脚本管理器之类的设备在设备上作为“SuperUser”或root资源管理器将文件放回原处并给予正确的权限。
在具有安全内核的设备上键入adb remount将允许您以读写方式重新安装整个系统，并且您可以根据需要进行操作。如果不安全，您可能最终会做类似的事情
adb root
remount
否则您可能会发现整个控制台都没有 super 用户权限，因此需要将Adb Shell放入设备 shell (在该 shell 中或您拥有 super 用户权限)，然后执行要尝试的命令。
adb shell
su
mount -o rw /system
remount /system
我最近发现，您可以通过adb控制台上的单行和单个返回键来获得相同级别的访问，如下所示:
adb shell su -c mount -o rw,remount /system
这会将参数传递给单个字符串adb shell-> super 用户访问->传递命令->以读写方式安装->重新安装命令->到系统分区。
如果愿意，可以使用上述命令从控制台获取 super 用户权限，并将字符串回显到default.prop文件中，而无需反编译内核。
就我而言，我只是重复了几次相同的命令，并用相同的内容覆盖了default.prop，只调整了我喜欢的特定变量，如下所示:
请注意，第一行仅使用1>，这样可以有效擦除或覆盖default.prop文件，因此其余各行也需要遵循。我使用2> like >>，因为这会追加到文件的以下行。
adb shell su -c echo ro.secure=1>default.prop
adb shell su -c echo ro.allow.mock.location=0>>default.prop
adb shell su -c echo ro.debuggable=1>>default.prop
adb shell su -c echo persist.sys.usb.config=mass_storage,adb>>default.prop
adb shell su -c echo persist.service.adb.enable=0>>default.prop
对于4或5行代码，这是相当快速且有效的，但是当您用许多行测试重写大型文件时，这是不切实际的。您可能要看一下bash脚本中带有循环功能的grep之类的内容，以过滤大文本/脚本/配置文件的特定行，但是对于此示例以及您的系统vold文件，这应该足够了。
我认为这应该足以(请帮我打扰)用足够的信息(危险)给你ARM :)
关于这一点，请确保您已备份设备，然后再使用该系统。它们与linux非常相似，但它们也有很大不同!注意此警告，请确保立即备份您的EFS分区!! Efs包含设备的IMEI编号，而这确实是您不希望损坏或丢失的东西。我亲眼目睹了会发生什么；您甚至不需要偶然调用EFS分区来破坏它....您只需要在调用错误路径的显式路径时犯一个错误，它就可以消除您的IMEI!
关于android - 从Android中的ADB Shell手动安装SD卡，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22549489/