冲突是和你当前的 branch 有冲突。你当前指向的是 master ？还是自己改过的 branch ？
另外用 pull --rebase 比较好。

@makendk
做完 fastboot oem unlock 之后可以直接烧录所有分区（当然还会有一些检查），为何要进入 recovery 。
oem lock/unlock 的状态是在手机里，并不是原始镜像上（ dm-verity 的检查倒是在 boot.img 里）。
参考这个 boot flow ：
https://source.android.com/security/verifiedboot/verified-boot.html

不同厂商实现不一样，很少有完全符合标准的。

@makendk 不知道你在说啥， bootloader 不是很懂，但是反编译 bootloader 是什么鬼？
我的理解是：
默认状态下是 OEM lock 的状态+原始镜像。进入 fastboot 状态（ adb shell+reboot bootloader)，做 oem unlock ，然后可以烧录兼容镜像（用 Key 签名的镜像），后面就好办了。

@makendk
你确定能改 system.img ? 如果有 dm-verity ， system.img 是要靠 boot.img 里的东西去验证的，改了就对不上了。
其实这是一个信任链的关系， bootloader 保证 boot.img 的正确性， boot.img 保证 system.img 的正确性。

system.img 改 777 是能保存的。

有 SU 不代表 ROOT 了这个系统，用 AOSP 的 code 非 user 模式下编译出来的镜像都是带有 su 工具的，只是能通过 adb shell 或是串口敲个 su 进 root 罢了，系统本身并不是 root 状态。

SELinux 解释起来比较复杂，简单说关闭 SELinux 必须需要改到 bootloader （有 cmdline 给 android 的），或是 boot.img(SELinux 的 enable 在 init 里）。 SELinux 本身就是为了限制 root 而生的，这是一种 MAC 的机制，改成 777 只能过 DAC 检查。另外 SELinux 可不是拒绝读写文件这么简单了。

密码保存的方式至少是 MD5 转换后，比对是否匹配。任何能看到密码本身的设计都应被定义成严重 BUG

有一种东西叫 media scan ，会自己找的。
退一万步说，就算自己要实现去扫文件，如果别人外接了一个 2T 的硬盘，各种目录，各种媒体文件，你能保证效率吗？
优先使用 media scan 的结果， ls 有人贴了。即使要自己扫描，也是扫出多少显示多少，边扫边显示，优化好这个逻辑即可。

PS1 ，这 TMD 是我 5 年前做山寨平板的需求。
PS2 ， AndroidN 还有以后的版本能不能这么干都是问号。

前提是没有做 git gc ，而没 gc 就太简单了。
1L 的做法就可以，你可以选择用 git fsck --lost-found 找到最后一个提交的 commit id 就可以。

@Tuisku 还是有点不太理解场景。如果你可以靠近物理机本身，那就不是问题，如果不能，那么是不是类似在本地上打开一个虚拟的屏幕接上去？这样不就可以直接粘贴复制了么？
难不成，一个超长 vga 线直接接到家门口。。。

@Tuisku 没法到机房？你怎么控制的？

理论上，只是理论上，你可以通过闪屏幕，输出数字信号，或是模拟信号，外面拿个接收器接受了，翻译一把。
理论上（不知道这个是不是违规）可以操控一个 gpio 管脚，然后拿一个接收器接受再翻译。
实际上，只能把源文件转码成容易识别的字符然后出来 OCR 。


其实，把硬盘拿走不就行了[手动滑稽]

@hjc4869
@EricCartman
没人说不能曝光狗东，单纯觉得在 V 站要库不好。

公开讨论这个，不太好吧

短期之内换不了房了呗。。。你没买过房又没影响的咯。。。
政策，你看看就好了啊，过段时间就会变的。想当年买房时候，还完贷款还算首套呢。

条件不足。最好多了解了解再说，比如华为也是很大的企业， A 部门和 B 部门可能一个吃土，一个吃肉。。。