展会只有三天，版本也只活三天：活动版怎么快、怎么收

先说一个时间很紧的处境：三天后有一场展会，你需要在展台那几台平板上装一个"专门给这场展会看"的版本。——它要和正式版长得不一样：启动页换成这次的主视觉，主色跟着主视觉走，首页多一个现场活动的入口，几个日常用的模块这次不需要出现。——而三天之后，这个版本就没用了——展台拆了，平板收进箱子，谁也不想再看到它。

这类需求的特点很清楚：时间短、改动集中、用完即弃。——而它偏偏最容易被做成"临时糊一把"——因为"就三天嘛"，于是不建项目、直接在正式版上乱改，改完才发现正式版的包也被污染了。——等到下一场展会，你打开正式版，发现上次为了展会加的那个入口还在，而你已经不记得当时还动过哪些地方。

「安卓修改大师智改工坊」在这类需求上并没有一套"活动版专用"的做法——它用的还是同一套：建一个项目、用一句话说清要改什么、打完包验证一下。——区别只在于"这个项目从一开始就注定要被删掉"——而这反而要求你在动手之前就更早想清楚：它要活多久，活到什么时候，谁来收。

先把一句话说明白：活动版不是"另一个应用"，而是"同一个应用的另一次打包"。——工程是同一份，功能是同一套，差别只在身份和几处入口。——所以你不需要重新开发一个东西，也不该重新开发——三天时间不够，也不值得。

只需说话，就能让应用变成你想要的样子。而在"只有三天"这个场景里，这句话的意思是：把"这场展会要什么样"说成一段完整的话，交给它去改；而"三天之后怎么收干净"，得你自己在开始之前就想好。想先看看它怎么建项目，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，拿一个自己的应用建一次项目——你会注意到它会给新项目建一个八位随机名的目录，那个目录就是将来要删的东西，也是"收干净"这件事的落点。

一、先分清活动版和正式版到底差在哪六处

"给展会做个版本"这句话，听起来已经很具体了——而它落到操作上，会散成六处具体的改动。——而如果不把这六处先列出来，你就会在展会前一天还在想"是不是还有哪里没改"。——六处列清，剩下的是机械动作；六处没列清，剩下的是猜。

一是应用名。——正式版叫"XX 助手"，活动版可能要让桌面上的名字带上展会名，比如"XX 助手 · 春季展"。——这里最容易踩的是长度：名字变长之后，桌面图标下面的字会被截断，而截断之后显示的是哪几个字，你在电脑上是看不出来的——必须装到机器上看。

二是图标。——展会上通常会有一套主视觉，图标要不要跟着换？换了更统一，不换更省事——这需要提前定。——而如果要换，就得准备多个密度档的图，而不是只给一张大图让它自己缩——一张 1024 的图缩到 48 像素，边缘会糊。——另外，如果原来的图标是自适应图标（前景加背景两层），换图时要注意保留安全区，否则在某些机型上会被裁掉一圈。

三是启动页。——这是活动版最值得改的一处，因为它是"打开就看见"的第一屏。——而改启动页有个稳妥的边界：换配色、换文字、换那张主视觉，但不要动版式和元素位置——版式一动，不同屏幕比例上的对齐就会散。

四是主色。——展会主视觉一般有一个明确的颜色，把它换到应用里，整体气质就跟着变了。——而换主色之前要先做一件事：把用到这个颜色的地方列出来——标题、按钮、选中态、进度条、链接——因为有些颜色是"主色的深浅变体"，只换主色不换变体，界面上会同时出现两种不搭的蓝。

五是首页入口。——活动版通常要多一个入口，指向"现场活动"或"扫码领资料"这类页面。——而这里有一个很实际的判断：如果这个入口指向的内容需要联网、而且那个页面还没做好，那先别加——展会现场的网络是最不可靠的一环，一个点开就白屏的入口，比没有这个入口更伤。

六是"这次不要出现的东西"。——这一处最容易被漏掉，因为它不是"改"，是"藏"。——日常用的那些模块——内部审批、库存盘点、员工考勤——在展台的平板上不该出现，因为参观的人会随手点。——而"藏"这件事必须落在需求里说清楚："首页不显示这几项"，而不是"删掉这几项"——删掉是不可逆的，藏起来是可逆的，而活动结束后你未必还想再改一次。

把这六处写下来，你会发现它们的形状和"多校区"那类需求很像：前五处是"看得见的差异"，第六处是"决定它能不能被放心交出去"的差异。——而顺序也值得注意：先定第六处，再定前五处。——因为"哪些不该出现"决定了这个版本能不能放到公共场合，而"名字和颜色"只是好不好看。

还有一处不在六处里、但必须单独提：版本号。——活动版的版本号建议比正式版高，而不是低。——原因是安装的时候，安卓会比较版本号——版本号低的新包，装不上已经装了正式版的那台机器，除非先卸载。——而展会前一天在现场卸载重装，是最不想发生的事。

所以这张清单可以缩成一句话：改名、换图、换启动页、换主色、加一个入口、藏几个模块，版本号往上走一格。——而这句话本身就是一段可以直接发给工具的需求——写得越像这样，改出来的东西越接近你想要的样子。——反过来说，如果你只写"做个展会版"，那它只能猜，而猜出来的六处，你一处都不会满意。

二、倒排一遍：从开展前七天到撤展后两天

时间紧的项目最怕"按顺序做"——先想需求、再改、再打包、再装、最后发现少了一样东西。——更稳的办法是倒排：从最后一个动作往前推，把每个动作放在它必须完成的那一天。——而"最后一个动作"不是"打包完成"，是"撤展那天把平板恢复干净"。

时间	这一天必须完成的事
开展前 7 天	六处清单定稿，主视觉和图标素材收齐
开展前 5 天	建项目、反编译完成，工程能正常打开
开展前 3 天	六处改完，打出第一个包，装一台机器看过
开展前 2 天	冻结改动，只修问题不加东西；补齐所有展台平板
开展前 1 天	现场网络实测一次，包里留一份离线兜底
活动三天	只记录问题，不改包；真要改就记下来留到下次
撤展后 2 天	平板卸载恢复、安装包归档或删除、项目目录处理

这张表里最容易被压缩的是"开展前 7 天"那一行。——很多人是从"开展前 3 天"开始做的，因为需求是那时候才下来的。——而从 3 天开始做，就意味着"冻结改动"那一天没有了——你会在开展前一天还在改，而改完没有时间验证。

所以如果真的只有三天，那就把六处清单砍到三处。——经验上优先级是这样的：先"藏不该出现的"，再"改启动页"，最后"改名字和颜色"。——而图标和首页入口可以放到下一场——因为参观的人记不住你的图标，但会记住"点开就白屏"。

第二容易被跳过的是"活动三天只记录不改"。——展会上一定会有人提意见："这个字太小""这个按钮点了没反应"。——而如果当场改，你就是在用一个没验证过的包，替换一个已经验证过的包——风险比问题本身大得多。——正确做法是记在本子上，撤展之后再改；而如果问题严重到"不改就没法演示"，那就退回上一个包，而不是现场改。

还有一件小事，但它能救你一整天：把"开展前 5 天反编译完成"当成一个必须验收的节点。——因为反编译这一步有个特点：它要么很快，要么一直不成功——而"一直不成功"通常不是等一等就好，是包本身有问题（加了壳、工具版本对不上）。——如果这一步拖到开展前 1 天才发现过不去，那就没有备选方案了。

最后说一句关于"倒排"的实话：它的价值不在于严格执行，而在于让每一件事都有一个"最晚什么时候做"。——现实中总会延后，而只要有这个最晚时间，你就知道哪一件可以延、哪一件延了就会连环崩。——而在活动版这件事上，唯一延不得的是"装到真机上看一眼"——因为它是唯一能把"我以为改好了"变成"确实改好了"的动作。

三、建项目这一步别省，它决定了三天后好不好收

"就三天，还要建项目？"——这是活动版最典型的省事冲动，而它省掉的东西，恰恰是三天后最需要的东西。——因为建项目这件事，做的不是"把文件整理好"，而是"把这三天里所有的改动，装进一个可以整体扔掉的东西里"。

建一个项目，工具会按顺序做五件事。——先建一个八位随机名的目录（小写字母加数字），然后在里面拷一份源包，接着把你选的图标存进去，再写一份 config.ini 记住这个项目的名字、源包、图标和签名设置，最后才跑反编译。——这个顺序是有讲究的：反编译放在最后，因为前面任何一步失败，都不该留下一个"半成品工程"——而只要 config.ini 还没写成，这个目录在项目列表里根本就不存在。

那个八位随机名的目录名，是这件事的关键。——它不好看，也不方便记，而它唯一的用途是"不重名"——你同时开三五个项目，名字可能是"展会版""展会版2""展会版-备份"，而目录名永远不撞。——更重要的是：它让"删哪个目录"这件事变得没有歧义——你要删的是那个八位名，而不是某个你凭印象记得的文件夹。

config.ini 里记的东西，为什么对活动版特别重要？——因为它记的是"这个项目的身份"——名字、源包、图标、签名。——而活动版最怕的就是这几样混了：把正式版的签名拿出来打活动包，或者把活动版的图标打进了正式包。——一个项目一份配置，配置错不了，包就不会错。

反过来看"不建项目、直接在正式版上改"会发生什么。——第一，正式版的工程被改动了，而你没有一个"改之前"的副本可以回退——改包这条路没有版本控制，"回到昨天"这件事只能靠目录拷贝。——第二，改动没有记录——history.ini 是跟着项目走的，你在别的目录里改了什么，它不知道。——第三，三天后你想"把展会的东西全撤掉"，就得凭记忆逐条撤销——而记忆是最不可靠的东西。

所以活动版的正确起手式是：拿正式版的源包，新建一个项目，项目名里带上展会名和日期，比如"春季展 0412"。——名字里带日期这一条不是洁癖——它是三个月后你唯一能判断"这个项目还有没有用"的线索。——而在项目列表里，这些项目是按建立时间倒序排的，最近建的在最上面——所以展会版会一直待在最前面，直到你把它删掉。

还有一个很好用的性质：整个项目目录是可以整体拷贝的。——如果这次展会版和上次那场只差主视觉，你可以把上次的项目目录拷一份、改目录名、刷新列表——就有了一个新项目，工程、配置、历史都在。——然后只需要改那几处真正不同的地方——这比从零建项目省下的是"等反编译"的那几分钟，而在开展前一天，那几分钟很值钱。

顺便说清一个边界：项目目录整体拷贝之后，两个项目就各自独立了——改一个不会影响另一个。——这是好事，也是陷阱：好事是你敢放手改；陷阱是你以为"它们还连着"，于是只改了一边，却以为两边都改了。——所以拷完之后第一件事，是刷新列表、确认两个项目的名字和图标各是各的——三秒钟的事，能省掉一次打错包。

四、两个自家应用的实例：以前怎么做，现在一句话

讲两个我们自己踩过的例子。——都是自家的、内部在用的应用，不是什么特殊的东西——正因为普通，才好对照。——每个例子按三句话说：以前怎么做、现在一句话怎么做、改完怎么验证。

例一：自家的展位导览应用。——这个应用是我们自己做的，用来在展台平板上给参观者看展位图、查日程、留联系方式。——它一年要用好几场展会，而每一场的主视觉都不一样——所以它是一个"天生就要反复换皮"的东西。

以前怎么做：——每次展会前，找开发同事排期，改六七个资源文件——string 里的应用名、三张不同密度的图标、启动页的背景图、colors 里的主色、还有首页那张日程卡的标题。——改完要重新编译、导包、发到平板、装上试——一轮下来大半天，而如果主视觉在开展前两天才定，这大半天就得挤在最后两天里。——更麻烦的是：改完之后，上一场的版本就没了——下一场想"参照上次那个配色"，只能凭截图猜色值。

现在一句话怎么做：——建一个项目，然后发一段需求："把应用名改成『展位导览 · 春季展』，启动页背景换成附件这张主视觉、文字改成『欢迎来到春季展』，主色改成 0b62d6 的深一档，首页日程卡的标题改成『今日日程』，内部用的『签到后台』入口这次首页不显示。"——一段话，六处改动，一次改完。——改完直接打包，包里带着这一场的全部身份。

改完怎么验证：——三步，五分钟。——第一步看项目列表：名字和图标对不对——这一步不用装机。——第二步装一台平板：看桌面上的名字有没有被截断、图标边缘有没有被裁、启动页是不是立刻就出现。——第三步点一遍首页：确认该出现的入口都在，那个"不该出现"的签到后台确实没在。——这三步做完，才敢往剩下那几台平板上装。

例二：自家的渠道答谢会报名端。——这是我们内部做的一个很小的东西，只有两个页面：报名表单和签到名单。——它平时给渠道同事用，而每次答谢会，它需要换一个名字、换一个主色、并且在签到页顶部显示"XX 年度答谢会"。

以前怎么做：——三个字段而已，直接在工程里手改，改完重新编译——听上去五分钟，实际上要先把编译环境打开、等 Gradle 跑完、再导包、再传到手机上。——而最尴尬的一次是：改完忘了改版本号，装到已经装过旧版的那台手机上，提示"应用未安装"——现场又没带电脑，只能先用旧版顶上，签到页顶部的会议名是上一场的。

现在一句话怎么做：——"应用名改成『答谢会签到 · 2026』，主色换成这个附件里取的色，签到页顶部的标题文字改成『2026 年度渠道答谢会』，版本号往上加一格。"——最后那半句"版本号往上加一格"是那次事故之后固定加进去的——它不是技术细节，是现场经验。

改完怎么验证：——这次多了一步——先在一台"已经装过旧版"的手机上直接装新包，看它是不是顺利覆盖。——能覆盖，说明包名和签名都没变、版本号也确实往上走了；不能覆盖，就说明这三样里有一处错了，而现在发现，比在会场发现好。——而这一步之所以能提前做，是因为它只需要一台手机和一分钟——不需要电脑，也不需要网络。

五、打包和安装：现场最常出的三个岔子

包打出来只是"有了一个文件"，而展会上真正会出问题的地方，是"这个文件装到那台平板上"。——下面这三个岔子，几乎每一场活动都会撞上一个。

岔子一：提示"应用未安装"。——这句话是安卓最常见、也最不说明问题的一句话——它不说原因，只说结果。——而原因无非是四种：包名和已装的那个不一样、签名不一样、版本号比已装的低、存储空间不够。——而你只要记住一条判断顺序：先看包名，再看签名，再看版本号，最后看空间——因为前三个是"改包时决定的"，最后一个是"机器状态"。

岔子二：签名变了，于是必须卸载重装，而卸载会清掉数据。——这是最容易在展会前一天炸的一处。——因为安卓判断"是不是同一个应用"，看的是包名加签名——两个都一致才允许覆盖安装。——而签名的选项里，有一种是"每个包随机生成一个"——它的好处是不用准备密钥文件，坏处是每个包的指纹都不同——于是新包永远装不上旧包，必须先卸载。

所以在活动版上，签名这件事要提前定死：用同一份签名，从第一场到第 N 场都不换。——如果这个应用之前是用开发机上的调试签名打的，那活动版也沿用那份——因为展台平板上装的是它，换了签名就得卸载，而卸载之后，那台平板上攒了几场的数据就没了。——而"数据"这件事在展台上可能只是几条测试记录，也可能是一上午的参观登记——你赌不起。

岔子三：包传不到平板上。——展会现场常见的方式是微信传文件、扫码下载、数据线拷——三种方式各有各的坑。——微信传 apk，有些版本会把它当成"不支持的文件类型"而不让直接打开；扫码下载，需要一个能放包的地址，而现场网络未必通；数据线拷，需要那台电脑上装了驱动。

最稳的做法是"两种都带"。——包里带一份在笔记本上（数据线随时可用），同时把包放到一个手机能访问的地址（内网或者公共网盘都行）。——而如果有三台以上的平板要装，就别一台一台传——找一个 U 盘或者一个能开热点的手机，比什么都快。——这些不是技术问题，是"到了现场才发现"的问题，而它们提前一天都能解决。

顺便说清打包那一步在做什么，因为知道它在做什么，你才知道报错时该看哪儿。——打包是四步：先回编成未签名的包，再对齐，再签名，最后校验签名。——四步里任何一步失败，工具都会停下来，并把原因写进日志——而日志里第一句通常是"哪一步、什么错"。——所以遇到打包失败，第一件事不是重试，是打开 pack.log 看第一句。

而如果四步都过了，工具还会做一次签名校验——校验没通过，它会明确告诉你"这个包不要用"。——这句话值得当真。——因为一个签名有问题的包，可能装得上、可能跑得起来，然后在某个机型上被系统拦掉——而你在展会上没有时间排查这种事。

把这三个岔子反过来看，其实就是三条准备：签名固定不换、版本号往上走、安装包两种方式各带一份。——三条都是在"开展前"做的，而它们在现场能省下的时间，是按小时算的。——而这三条没有任何技术门槛——它们只要求你在动手之前，把"那天会发生什么"想一遍。

六、三天里怎么确认"装上去的确实是对的"

"改好了"和"验证过了"是两件不同的事，而活动版最危险的状态，是"我以为改好了"。——因为改完的那一刻，你看到的是项目列表里的名字和图标——那是工具界面在告诉你"配置写对了"，不是应用在告诉你"我变成这样了"。

验证分三层，一层比一层接近现场。——第一层是"这个包能不能装"——装得上，说明包名、签名、版本号这三样是自洽的。——第二层是"装上之后六处对不对"——名字、图标、启动页、主色、入口、该藏的藏了。——第三层是"现场会怎么用它"——把网络关掉，看它是不是还能撑住。

第一层没什么技巧，但有一个顺序值得记住：先在一台"已经装过旧版"的机器上装。——如果它顺利覆盖，你就同时验证了三件事——包名没变、签名没变、版本号确实是往上走的。——而如果先在一台干净的机器上装，这三件事一件都验证不了，你只会得到一个"装上了"的假安心。

第二层的六处里，只有三处必须装机才能看：名字有没有被截断、图标有没有被裁、启动页是不是一打开就出现。——另外三处——主色、首页入口、藏起来的模块——只要点一遍首页就能看全，而它们不需要"换机型"，一台机器就够。——所以第二层的成本其实很低：一台机器、五分钟、点一遍。

而"名字被截断"这件事值得单独说一句。——桌面图标下面的文字，能显示多少个字，取决于机型的桌面布局和字体大小——你在电脑上看到的名字是完整的，在手机上可能只显示前六个字，后面变成省略号。——而省略号之后，两个不同版本的包看起来就一模一样——展台上有人问"这是哪个版本"，你答不上来。——所以名字短一点、把区分信息放在前面，比"名字完整"更实用。

第三层最容易被忽略，而它恰恰是展会现场最真实的一层：把 Wi-Fi 和移动数据都关掉，再用一遍。——因为展会现场的 Wi-Fi 通常是"能连上、但很慢"或者"能连上、但要认证"，而这两种状态和"没网"对应用的影响，有时候是一样的。——如果关掉网络之后，启动页卡住、首页白屏、点任何入口都没反应——那这个包在展台上就是个砖头。

所以"加一个入口"这件事，在活动版上要额外加一个条件：这个入口指向的内容，最好已经在包里。——也就是说，与其加一个"打开网页"的入口，不如加一个"打开本地页面"的入口——前者依赖网络，后者不依赖。——而如果确实必须联网，那就在展台平板上提前把那个页面打开、留在后台——这是最土、也最有效的兜底。

还有一张纸，建议真的写出来：装机表。——左边写平板编号（或者机身上的资产标签），右边写"装的哪个包、什么时候装的、谁装的"。——三台以下是多余的，五台以上能救命——因为展会第二天一定会有一台机器出问题，而你需要十秒钟内判断"它和别的那几台是不是同一个包"。

最后一句关于验证的话：验证不是"确认自己没做错"，是"提前把会在现场发生的事，挪到有电脑、有网络、有时间的时候发生"。——同一件事，开展前一天发现是"再打一个包"，开展当天发现是"这场活动就废了一半"。——而这两者之间，只隔着一台平板和五分钟。

七、撤展之后：三个动作，一个顺序

活动结束那一刻，人的状态是"终于完了"——而正是这个状态，让"收尾"变成了最容易被糊过去的一步。——而收尾糊过去的代价，不在这一场，在下一场：你会打开一个不知道是什么的项目，或者装一个不知道是哪场的包。

动作一：处理平板。——展台的平板如果是临时借的、租的、或者要还给别人的，那第一步就是把活动版卸掉——因为包里带着展会的主视觉和名字，留在机器上不合适。——如果是自己长期用的，那就装回正式版——注意这里有一个坑：活动版的版本号比正式版高，所以"装回正式版"这件事，在安卓看来是"降级"，装不上，必须先卸载活动版。

这一条很多人不知道，于是撤展那天会卡在"怎么装不回去"上。——而它其实是好事：正因为降级装不上，你才不可能把活动版和正式版搞混——两个包在机器上只能存在一个。——所以撤展时对平板的动作是明确的：先卸载，再装正式版（或者干脆空着）。

动作二：处理包。——这一场的安装包，建议留一份，而且只留一份。——留的原因很实在：下一场如果要"参照上一场"，你需要的不是整个工程，是那个包——把它装在机器上看一眼，主色、启动页、名字长度，全在眼前。——而"只留一份"的原因是：包是会繁殖的——你会在桌面、下载文件夹、微信文件传输助手、U 盘里各找到一份，而它们未必是同一个版本。

留的那一份要有名字。——打包出来的文件通常是按项目名或者时间命名的，而"20260412-spring.apk"这样的名字，三个月后你还看得懂；"unsigned-aligned-signed.apk"这样的名字，三天后你就看不懂了。——改名的时机是"打完包、验证完、确认这个包要留"之后——不要在验证之前改名，因为验证没过的包不该有名字。

动作三：处理项目目录。——这一步才是"删"，而删这件事，工具本身是有保护的。——删一个项目要过四道检查：路径不能为空、项目根目录必须已经确定、要删的目录不能就是根目录本身、要删的目录的上一级必须正好是根目录。——四道检查合起来做一件事：保证你删掉的只能是"根目录下面的一个项目"，而不可能是一个更大的东西。

还有两个细节，是"删"这件事上很容易被误解的。——第一，如果目录里有只读文件，工具会先把只读属性清掉再删——所以"删不掉"很少是因为权限，更多是因为有文件正被别的程序打开。——第二，如果目录本来就不存在，这次删除算成功——这个设计的意思是：你点两次删除，第二次不会报错。——而这两条加在一起，说明"删"这个动作被设计成"尽量做成"，而不是"稍微不对就拒绝"。

但"能删"不等于"该删"。——活动版的项目目录，建议先留一周再删。——理由很朴素：展会结束后的一周内，一定会有人问"那个版本能不能再给我一份"——而那时候你需要的是"能立刻打一个一样的包"，而不是"从零再改一遍六处"。——一周之后没人问，再删。

顺着这个思路，收尾的顺序应该是：先归档包，再处理平板，最后删项目目录。——因为包是"结果"，项目目录是"过程"——结果留下了，过程才可以安心丢掉。——而反过来做——先删项目、再去想包放哪儿了——你会发现包也跟着没了，因为包通常就躺在项目目录里。

最后提醒一句：删之前看清目录名。——你要删的是那个八位小写字母加数字的目录，而它旁边可能躺着"备份""归档""旧版"这类你自己建的文件夹——那些不在项目根目录下面，工具也删不到它们。——所以"清干净"这件事，工具只能替你清它自己建的东西；你自己建的那些，还得你自己记着。

八、把"活动版"做成一套模板，下一次省一半时间

如果一年要办好几场活动，那"活动版"就不该是一次性的手艺，而应该是一个可复用的东西。——而可复用的关键不是"存一个包"，是存三样东西：一段需求文本、一叠素材、一张装机表。

第一样：需求文本模板。——把上一节那六处写成一个填空句式，每一场只换括号里的内容。——比如："应用名改成『（应用名）·（活动名）』；启动页换成附件主视觉，标题文字改成『（欢迎语）』；主色改成（色值）；首页保留（入口清单），（不该出现的模块）这次不显示；版本号往上加一格。"——这样一段话，每次改五个括号，就完事了。

而模板的价值不只是"省打字"。——它真正省的是"想"——因为每一次都要重新想"要改哪几处"，而每一次想的结果都不完全一样。——于是你能从三场的包里看出三种风格：第一场改了名字没改主色，第二场改了主色没藏模块——而参观的人看不出这是同一个东西，你自己也渐渐说不清"标准的活动版长什么样"。

第二样：素材。——每次活动都会收到一堆图：主视觉一张大横图、图标一张方形图、可能还有几张现场照片。——而图标这一项最容易出问题：给一张 1024 的方图，让工具自己缩——缩出来的效果在不同机型上不一样。——所以素材这一叠里，图标要按密度档准备好几份，文件名上带着尺寸，谁拿到都知道该用哪张。

还有一个细节：如果这个应用的图标是自适应图标（前景一层、背景一层），那换图的时候要一起换，而且要留安全区。——因为自适应图标在不同厂商的桌面上会被裁成不同的形状——圆形、方形、水滴形——边缘那一圈随时可能被切掉。——所以主视觉里如果有重要的字或者标，别放在靠边的位置。

第三样：装机表。——这张表每场都长一样，只有填的内容不同。——把它做成一个表格文件，第一次用完别删，下次清空内容继续用。——而它最大的作用是"交接"——活动当天你未必在场，而拿着这张表的人，知道哪台机器装的是哪个包、什么时候装的。

九、五个最常被问到的问题

问一：就三天，能不能不建项目，直接在正式版上改？——能，但不建议——因为你没有"改之前"的副本。——而改包这条路上，"回到昨天"这件事只能靠目录拷贝：建项目的时候工具会把源包拷进项目目录，那份拷贝就是你唯一的退路。——省下这三分钟，代价是"三天后没法干净地撤回去"。

问二：活动版要不要单独一个包名？——看它要不要和正式版同时存在。——如果展台平板只装活动版、正式版在别的机器上，那包名不用改；如果要同一台机器上两个都有，那包名必须不同，否则装一个顶掉一个。——而改包名有一个连带影响：它就是一个"新应用"了，装在机器上不会覆盖旧的那个，也不会继承旧的数据。

问三：展会三天里发现 bug，要不要当场改？——除非"不改就没法演示"，否则不要。——当场改意味着你要用一个没验证过的包，替换一个已经验证过的包——而这个替换如果出问题，你连退回去的时间都没有。——真要改，也先在一台备用机上改、验证，确认无误再换——不要在所有机器上一起动。

问四：图标能不能只给一张大图？——能装，但显示效果看运气。——因为桌面上显示的图标，是从包里对应密度档取出来的——如果只放了一张大图，系统会缩，缩到小尺寸时细节会糊、边缘会毛。——而图标是"第一眼"的东西，在展台上它比启动页还先出现。

问五：撤展后项目目录能不能直接删？——先做两件事再删：确认包已经归档、确认没人还要这一版的包。——而删的动作本身是安全的——它能删的只有项目根目录下面那一层，删不到别的地方。——但"安全"和"该删"是两回事：留一周，比当天删掉更划算。

十、一张能打印出来勾的活动版检查表

下面这张表，是从前面所有内容里挑出来的"不做会出事"的十二项。——它不追求完整，只追求"每一条漏掉都会在展会当天让你难受"。——打印出来，一边做一边勾，勾完才发到展台上。

阶段	要勾掉的一项
开工前	六处清单写下来了，而且写清了"哪些不显示"
开工前	签名用哪一份定了，而且和展台平板上已装的那份一致
开工前	版本号定成"比正式版高一格"
建项目	项目名里带了活动名和日期
建项目	反编译跑完、工程能打开，这一步不拖到最后一天
改	一段话把六处写完，没有分五次说
改	图标按密度档给齐，不是只给一张大图
打包	四步都过了，签名校验没有报错
验证	先在"装过旧版"的机器上装，确认能覆盖
验证	关掉网络再用一遍，启动页和首页都不卡
装机	所有展台平板装完，装机表填了
撤展	包留一份带名字的，平板恢复、项目目录留一周再删

这十二项里，只有一项是"技术"：签名校验。——其余十一项都是"有没有想到"。——而这就是活动版这件事的真相：它不难，它只是环节多、时间紧——而环节多的事情，靠清单，不靠记忆力。

如果只能记住三项，就记这三条：签名别换、版本号往上走、先在装过旧版的机器上装一次。——前两条保证"装得上"，第三条保证"你知道它装得上"。——而展会上最贵的不是改错了一个字，是"该装的时候装不上"。

十一、用过的人怎么说

五条反馈里，两条讲签名、一条讲图标安全区、一条讲"藏"、一条讲收尾。——而它们有一个共同点：都不是"改得对不对"，而是"改完之后怎么给它收边"。——这也印证了前面那句话——活动版的功夫，大半在改动之外。

还有一条值得单独记住：那位做工业巡检的读者说"工程还是那份工程"。——这句话点出了"改包"这条路和"重新开发"的根本差别——你不是在造一个新东西，你是在同一份东西上换一层皮。——而换皮的好处是"随时能换回来"，这正是短期活动最需要的能力。

---

只需说话，就能让应用变成你想要的样子。——而在"只有三天"这件事上，安卓修改大师智改工坊省下的不只是时间，更是"敢在开展前一天动手"的那点底气。