更新包、缓存与数据落在哪：程序目录与手机目录是两回事（附迁移策略）

本文属于"新手上路"里的机制篇。主角是安卓修改大师智改工坊——一款 Windows 桌面工具：把安装包拖进来，用中文写一句需求，AI 在反编译出来的工程里改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

先说一个真实的小混乱。有位同事问："我昨天把工作目录换到了 E 盘，为什么手机里的应用还是找不到它下载的更新包？" 这两个问题里其实塞了三件不同的事：电脑上的程序目录、手机上的应用目录、以及应用自己下载的文件放在手机哪里。它们名字里都可能有"包名""应用名"，看起来像一回事，实际是三条互不相干的路径 —— 换盘换的是电脑上的目录，动不了手机上的一个字节；而应用在手机上把文件写到哪，是它自己的代码决定的，跟你在电脑上怎么放工程毫无关系。

这件事值得单独写一篇，是因为它同时踩在两条链路的交点上：一条是"改包"这条链路（工程、反编译产物、打包产物存在电脑哪里），另一条是"应用在设备上运行"这条链路（数据、缓存、下载的更新包存在手机哪里）。搞清楚两条链路各自的规则，很多"找不到文件""升级失败""改完更奇怪了"的问题会当场变成常识题。下面就从这两套目录开始。

一、先分清两套目录：程序自己的目录，和应用在手机上的目录

这两套目录最容易混，是因为它们都用"包名 / 应用名"来命名，也都存着"这个应用相关的东西"。但只要问三个问题，就永远不会搞混：谁创建的、在哪台设备上、谁负责清理。

对比项	程序自己的目录（工作目录）	应用在手机上的目录
在哪	电脑的硬盘上，形如 <盘符>:\AiApkEditor	手机的闪存上，形如 /data/data/<包名> 或 Android/data/<包名>
谁创建	智改工坊：自动挑盘后建出来	Android 系统在装机时创建、应用运行时往里写
装什么	工具链、项目、反编译产物、打包产物、日志	应用的配置、数据库、缓存、它下载的文件
谁清理	你（删除项目 / 换工作目录）	系统（清除数据 / 卸载应用），或应用自己
改包影响它吗	改包全程都在这里发生	卸载会清空；覆盖安装则保留

记住这张表的最后一行，就能回答开篇那个问题：换工作目录只影响电脑上的工程放哪，跟手机上应用的数据没有半点关系；反过来，手机上应用的数据会不会丢，取决于你在设备上是怎么装的 —— 是覆盖安装（数据保留），还是先卸载再装（数据清空）。

二、程序自己的目录：挑盘的三道判定与两个子目录

工作目录落在哪，不是一个固定值，而是启动时算出来的。规则是：依次尝试 D、E、F、G 四个盘，取第一个"可用"的，拼成 <盘符>:\AiApkEditor；四个都不行才退回 C 盘。 为什么是它们、以及为什么 C 盘放最后，和"文件落点"这件事的因果关系很直接：

三道判定的顺序也藏着设计意图：先试 D→E→F→G，最后才是 C。 C 盘是系统盘，装着操作系统和一堆程序，权限限制最多、也最不该拿来放大文件；所以哪怕 C 盘空间最大，它也只是兜底。挑盘的过程会被记下来（哪个盘因为什么原因没被选），在「参数设置」页能看到一句说明 —— 这解释了那个经典疑问："为什么我的工程跑到 D 盘去了，我明明习惯把东西放在桌面。"

工作目录下面约定有两个子目录，它们的分工非常清楚：

• tools —— 工具目录。Java 环境、aapt、apktool、签名与对齐工具、adb 这些组件都住在里面。它的定位方式是"先试约定位置，再在整个工具目录里递归搜索"：不登记、不写死路径，所以你把工具从一层目录挪到另一层、或者放一个带版本号的新 apktool 进去，重新打开程序就能认出来（工具目录里找东西有一个文件数量上限，防止某个巨型目录把启动拖死）。遇到多个 apktool 版本时，优先选版本号更高的那个。
• Project —— 项目目录。每导入一个安装包，就在它下面开一个8 位随机字符串的子目录当项目工作目录，项目名、包名、图标、历史这些信息分别记在各自的文件里，互不干扰。项目多了以后，这个目录就会慢慢变大 —— 一个项目里同时躺着原始包副本、反编译出来的整棵目录树、以及每次打包的产物。

还有一个"下载落点"值得单独点出来：需要更新工具链时（比如环境不齐点「立刻更新」），程序会把工具包下载到工作目录下的 download 子目录，再解压到工作目录根目录（包里的内容本来就是 tools 那一套）。为什么下载不落系统盘？因为工具包体积不小，落在工作盘上，既避开了系统盘的权限问题，也让"删除工作目录"这一个动作能把所有东西清干净。解压时还会按文件头判断格式（zip 还是 7z），不看扩展名 —— 这样服务端把地址里的后缀写错也不影响你解包。

项目目录里都装了什么，知道一次就够用了：config.ini（这个项目的基本信息，明文可编辑）、history.ini（每次点「立刻修改」追加一条需求原文）、图标文件（从包里原样取出，扩展名跟着原格式走）、source.apk（导入时的原始包副本）、反编译目录、build 打包产物目录、以及几份日志。这几样东西里，source.apk 是"改坏了能重来"的那条退路，所以它不是冗余，而是刻意留的一份底。

三、应用在手机上的目录：四个落点，各有各的脾气

换到手机这边，规则完全换了一套。Android 给每个应用划了几块地，名字和用途都不同，最要紧的是它们的可见性与清理规则完全不一样。下面这张表是这一章的骨架：

落点	大致路径	谁能看到	什么时候被清掉
内部存储	应用私有目录，普通用户和文件管理器都进不去	只有这个应用（和 root）	卸载必清；清除数据也清
外部私有目录	形如 Android/data/<包名>/ 下的 files 与 cache	老系统上文件管理器能翻到，新系统上基本看不到	卸载清（较新系统会连带删除）；清除数据也清
公共外部目录	下载、图片、文档这些公共目录	所有人都能看到（需要授权或用系统接口写）	卸载不清；要人手动删
缓存目录	内部或外部私有目录里那个专门的缓存子目录	同私有目录	系统在存储紧张时可能主动清理

四块地里最容易被误解的是最后一块：缓存目录不归应用独占。 它的意义是"随时可以丢"，所以系统在空间吃紧时可以主动清理它，应用自己也应当把它当临时目录用。这解释了一类很典型的报错："更新包明明下载好了，点安装却说文件不存在" —— 如果应用把更新包下到缓存目录、又过了很久才去装，中间系统清理过一次，文件自然就没了。合理的做法是把"要用的包"放在私有目录的普通子目录里，缓存只放"丢了也能重下"的东西。

公共目录则相反：它卸载不清。这对用户是好事（照片不会被卸载应用带走），对改包的人却不一定是好事 —— 旧版本留在公共目录里的东西，装了新包以后会被新包看到，出现"我改了默认配置，怎么还是旧值"这类现象。所以排查"改完没生效"时，除了看应用自己，也要想想它有没有把状态写到公共目录或外部存储里。

如果想在自己（或团队的）测试机上把这四块地实地看一眼，工具链里自带的 adb 就够了，三条命令各看一件事：列一下外部私有目录，看这台设备上装过哪些应用、每个应用的外层目录里有没有大文件；查一下某个包的信息，看它的数据目录与版本号到底是什么（这一步同时能验证"设备上装的到底是不是我刚打的那个包"）；看一眼公共下载目录，确认这个应用有没有把东西丢在大家都能看到的地方。三条都在自有应用、自有测试设备上做，几分钟就能建立"这个应用的文件都落在哪"的直觉 —— 有了这个直觉，再遇到路径类问题基本不用猜。需要提醒的是：较新系统上外部私有目录对文件管理器已经不友好，用命令行看反而更清楚。

四、Android 对存储的三次收紧：为什么"能写文件"这件事越来越难

如果你翻过一些老应用的代码，会发现它们写外部存储写得很随意；而新一代应用做同样的事，要绕好几个弯。这不是开发者的口味变了，而是 Android 一路把口子收紧了。理解这条时间线，能解释一大堆"为什么这个包的行为和文档不一样"。

1. 早期：写入外部存储要一个安装时就声明的权限。 应用只要在清单里声明了对外部存储的写入权限，安装时用户看到的就是一个"全都给它"式的授权，装完就能写公共目录。这一阶段的应用，很多直接把下载目录、缓存目录都放在了公共存储上。
2. 第一次收紧：权限从"装的时候给"变成"用的时候问"。 运行时的权限机制上线后，写入外部存储变成了弹窗申请 —— 用户随时可以拒绝。更关键的是，系统同时明确了一件事：应用写自己的外部私有目录（那个 Android/data 下带包名的目录）不需要任何权限。从此"自己的文件放自己目录里"成了推荐做法，因为它既不用申请权限，也不会被别人翻到。
3. 第二次收紧：分区存储。 新版本开始，应用默认只能看到自己那一份：自己的私有目录随便读写，别人的目录和公共目录不再随便扫。想要往公共目录里放东西，要走系统提供的媒体接口，或者走系统的文件选择器让用户自己指定位置 —— 对用户更安全，但应用"用路径遍历全盘找文件"的年代就此结束。这个变化对下载类行为影响最大：过去应用可以往公共下载目录一丢、以后再按路径捡回来；分区存储之后，路径能不能被自己再次读到，取决于它是用什么方式放进去的。
4. 第三次收紧：全面强制 + 特殊权限收口。 到了这一代，只有"面向旧版本、还没跟进"的应用还能吃到兼容期的宽松；一旦目标版本跟上，规则就是强制的。想拿"访问全部文件"这种宽权限，也不再是安装即得，而是要在系统设置里由用户手动打开一个专门页面去授权 —— 对一个正常应用来说，这条路既难看又容易被打回，不该作为常规方案。

这条时间线落到改包这件事上，能解释三类现象。第一，同一个应用的旧版本能写的位置，新版本可能写不了了：你导入的如果是一个老包，它会在公共目录里写文件；而你把它的目标版本改高之后再装，系统的规则变了，它可能就在同一个位置失败。第二，不同 Android 版本的设备上，同一个包的行为可能不一样：外部私有目录在较新系统上会随卸载被清掉，在较老系统上则可能残留，于是"卸载重装"在两种设备上得到的结果不同。第三，"找不到文件"越来越常见：路径没变，但可见范围变了 —— 应用自己写的文件，在一部分系统上它自己也未必能再按路径找回来，这属于平台规则，不是包坏了。

把这几条压成一句实用结论：私有目录是"自己的地"，公共目录是"大家的地"，缓存是"随时会被收走的地"。 一个应用把更新包放在哪块地上，直接决定了它"下载了会不会丢""卸载了会不会留""改包之后还找不找得到"。

五、改包之后，路径为什么会变

前面的两章讲的是"规则"，这一章讲"改动"。改包之后凡是和路径有关的问题，都来自三类改动之一：包名变了、签名变了、版本号变了。 三类改动的影响面完全不同，值得分开看。

把三类改动对照到"落点"上，就得到一张判断表。它回答的是同一个问题在不同场景下的具体表现：

你动了什么	手机上会怎样	典型症状
包名	数据目录整套换名，旧数据没人认领	"要重新登录""下载的文件不见了"；共享类功能报错
签名	装了别的密钥的版本就覆盖不上	"装不上：签名不一致"；卸载后数据全丢
版本号	低于设备上已装的版本时被拒	"装不上：版本比设备上的低"
应用名 / 图标（显示名）	路径不变、数据不变，只是"牌子"变了	基本无副作用；桌面可能缓存旧名

这里还有一个可以主动利用的技巧：签名密钥是可以替换的。 工具默认用工作目录根目录下的那一对测试密钥签名，把这两个文件换成你们团队自己的密钥，之后所有包都用同一对密钥签 —— 这样将来版本迭代时，就能一直覆盖安装、一直保留数据。反过来说，先用默认密钥打了包发出去、后来又换成自家密钥，那批设备就只能卸载重装一次。密钥这件事在项目开始时决定，成本最低。

"找不到文件"和"升级失败"的两条典型链路

链路一：更新包下载到哪，决定它会不会被清掉、还能不能按路径找回来。 应用要"下载更新包 → 校验 → 调系统安装界面安装"，中间那个文件必须活到安装那一刻。放在缓存目录 → 可能被系统清理；放在公共下载目录 → 在分区存储的新规则下，应用自己未必能再按路径读到（除非它当初是走系统接口放进去的、并能通过同样的方式取回）；放在自己的私有目录 → 最稳，但安装时还要走系统认可的"共享给安装器"的方式，不能直接把路径塞给安装器。这一串约束合起来解释了为什么"老包升级很顺、新系统上老出问题"。

链路二：包名变了，等于更新链路的起点没了。 应用检查更新时通常拿"自己的包名 + 自己的版本号"去问服务端；包名一改，服务端不认识这个身份，返回"没有更新"或者报错；即使你把包名改回来，本地那份"已下载的更新包"记录还在指向旧路径，也会先失败一次再重下。所以在自有应用上做"演示包/内测包"时，务必要么不动包名、要么明确接受"它是另一个应用"这件事，并在需求里写清数据的处理方式。

六、清理与迁移：改包前、改包后、以及项目侧各自该做什么

这一章把"落点"知识变成动作清单。三组场景，每组都有明确的先后顺序 —— 顺序错了，代价就是数据丢了或者白跑一轮。

迁移这件事还有一层：手机上"应用的旧数据"要不要搬。结论很干脆 —— 私有目录里的数据，除非应用自己提供导出功能，否则搬不动（分区存储之后更是如此）。所以给自有应用做这类改造时，最省事的方案往往不是"搬数据"，而是"让它重新生成"：登录态重新登一次、缓存重新下一次、下载包重新下一遍。真正需要保住的只有两类：用户自己产生的、重造不出来的内容（记录、照片、草稿），和那些"重新生成要花钱"的内容。对这两类，做法是在应用里做一次导出（写到公共目录或走系统分享），装完新包再导入 —— 这条链路只有自有应用才做得到，也正好落在工具的合规边界内。

电脑这边也有一次"迁移"，做起来比手机那边简单得多：整个工作目录可以整体搬走。 项目目录里记图标的位置用的是相对文件名（而不是硬盘绝对路径），就是为了让"整个项目目录拷到别处也找得到图标"这件事成立。所以换盘或换电脑时，把老工作目录里的 Project 整个拷到新工作目录下面，工程、历史、图标、源包都会跟着过去；tools 那一边则可以重新解压一份工具包，或者照原样拷过去。搬完做三件事确认：在「参数设置」里把工作目录指向新位置、跑一次工具链体检、然后回项目列表点刷新，随便开一个项目看历史与图标是不是都在。

七、两个自家实例：把路径这件事说清楚

下面两个例子都发生在自家应用和内部工具上，重点还是那三步：以前怎么做、现在一句话怎么做、改完怎么验证。

实例一：内部「巡检打卡」要出一个"演示包"，和现有安装并存。

场景：要给客户演示，需要在这台手机上同时保留现有的巡检工具，再装一个"演示专用"的版本，界面文案不同、数据互不干扰。这个需求其实只有一条路：改包名 —— 因为系统只认包名，包名一样就只能覆盖安装。以前的做法是把包名相关的字符串全盘 grep 一遍手工替换，然后回编、签名、安装；问题出在那些"带包名的路径与声明"上：下载目录是拼出来的、共享通道的声明里嵌着包名，漏一处就要在演示前夜抓头发。

现在一句话，并且把连带项写进去："这是我们的内部应用，要出一个演示包：把包名改成演示用的那个（写在需求里），所有带包名的路径、目录名与清单里的相关声明一起同步改；应用名改成『巡检助手 演示版』；原来的正式包不受影响。"点「立刻修改」，需求原文进历史，AI 在工程里改，改完留标志文件，主窗口自动弹打包窗口跑完四步。

改完怎么验证：第一步看"两个包并存" —— 装上演示包之后，桌面与设置里清楚地出现两个应用；第二步看"数据各归各" —— 打开演示包，是全新的状态（要重新登录），正式包的登录态不受影响；第三步看"路径类功能" —— 触发一次它自己会写文件的动作（比如导出当天的巡检记录），确认能找到、能写出、能再读回。三步都过，说明路径这件连带项改干净了。顺带说一句：如果这个演示包以后还要"回到正式包"上更新，记住它已经不是一个应用了 —— 数据不会互通，这是包名带来的必然结果。

实例二：自家「记账助手」把签名统一成自家密钥，避免下次丢数据。

场景：这个应用的早期内测包是用工具默认的测试密钥签的，后来团队想统一成自家密钥。第一次换的时候没人注意，结果新包装不上去（提示签名不一致），同事按提示卸载后重装 —— 本地的账目草稿全丢了，虽然能从服务器拉回来大部分，但两天的离线记录没了。以前这种事的教训只能靠"踩过一次就知道了"。

现在的做法是在动之前把顺序写在需求里，并且利用工具本身的一个设计：签名密钥就是工作目录根目录下的两个文件，可以替换。所以流程是两步：先把自家密钥文件替换进去，再发一句需求"这一版只抬高版本号、其余不改，用当前密钥签名"。改完打包时，四步链路里的最后一步会把签名证书信息打印出来 —— 那一行就是"这次用的确实是自家密钥"的证据，而不是靠猜。要发给同事之前，再加一句附件说明现在的密钥是团队的、以及"装这个包需要先卸载旧包，请先导出数据"。

改完怎么验证：看证书摘要（打包窗口里打印的那一行，确认是自家密钥）、看覆盖安装（同密钥的后续版本能直接覆盖，数据保留）、看数据目录（覆盖安装后打开应用，本地账目还在、不需要重新登录）。三件事连起来，就是"签名换过一次，之后再也不丢数据"的完整闭环。

八、用户评价：他们踩过的"落点"坑

以下引述来自内部试用与技术交流群里的使用体验整理，属于体验性反馈（文案性内容，非官方统计口径），供你对照自己的场景参考。

九、结语：两套目录，三条规则，一个顺序

把这篇收成一句话：程序自己的目录由挑盘规则决定（D→E→F→G→C、能读写、剩余不少于 1GB），应用在手机上的目录由 Android 的存储分区决定；两套目录互不影响，但改包的三类改动（包名、签名、版本号）会直接改到后者的命运。 再记住一个动作顺序：动手前抄下包名与版本号，想清楚要不要保数据；动手后验数据、验路径、验更新链路；清理时按项目粒度删，别把 source.apk 这条退路一起清掉。

这也是安卓修改大师智改工坊希望给你的那种确定性：只需说话，就能让应用变成你想要的样子 —— 你把"要做什么、要不要保数据、哪些不要动"说清楚，剩下的事情交给流程：工程落在自动挑好的盘上，AI 在摊平的目录里改，改完自动回编、对齐、签名、校验，再把包装到设备上让你亲眼确认。产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。