App被删除后，新安装的App再也无法访问之前创建的文件？

1.问题背景：

开发需求：需要存储公钥文件，要求app删除或者升级固件，公钥文件都不会被删除，同时目录要符合安全要求，普通用户无法访问。

2.问题描述：

方案选择：

• 存储在/data/data/com.xxx.xxx/ 目录下，app删除，里面的文件也会被删除。不符合需求。
• 存储到公有目录，缺乏安全。不符合需求。
• 存储到/cache/data/public这个目录（这个目录属于本人所在公司机型中framework层定制的目录），app删除，公钥文件不会被删除。符合需求。

问题：

app被删除后，再安装的app已经没有权限读写公钥文件了。

3.问题分析:

为什么app被删除后，再安装的app已经没有权限读写公钥文件了？

原理分析：

uid和gid

Uid（用户Id）：在Linux上，一个用户Uid标识着一个给定的用户。Android上也沿用了Linux用户的概念，Root用户Uid为0，System Uid为1000，并且，每个应用程序在安装时也被赋予了单独的Uid，这个Uid将伴随着应用从安装到卸载。

Gid（用户组Id）：Linux上规定每个应用都应该有一个用户组，对于Android应用程序来说，每个应用的所属用户组与Uid相同。

文件的权限控制

Android中每个app对应一个独立的uid（用户id）和一个独立的pid（进程id）。

Android系统本来基于Linux系统进行开发，Linux系统“一切皆文件”。Android也继承Linux的文件权限机制，系统中的每个文件和目录都有访问许可权限，用它来确定谁可以通过何种方式对文件和目录进行访问和操作。

文件或目录的访问权限分为只读( r )、只写(w) 和 可执行(x) 三种方式。

有三种不同类型的用户可对文件或目录进行访问分别是：文件所有者、同组用户、其他用户。

所有者一般是文件的创建者，所有者可以允许同组用户有权限访问文件，并且还可以将文件的权限赋予给系统中的其他用户。

从这个角度结合Android底层对uid的分配机制分析可知：app被删除之后再被安装，uid会被系统重新被分配，重新分配的uid和原来的uid已经不同了。也就是说，需要访问的文件在创建它的app被删除后，它的所有者已经不复存在。

这就是”为什么app被删除后，再安装的app已经没有权限读写公钥文件了？“背后的原理。

4.解决方案：

那么怎么解决问题呢？

赋予权限

根据需要给对应的文件或文件夹赋予对应的权限即可。

注意

一开始没彻底了解Linux中可执行权限的概念，导致没有给文件夹赋予x权限，重新安装的app无法进如该目录。

• r(Read，读取)：对文件而言，具有读取文件内容的权限；对目录来说，具有浏览目录的权限。
• w(Write,写入)：对文件而言，具有新增,修改,删除文件内容的权限；对目录来说，具有****新建，删除，修改，移动目录内文件****的权限。
• x(eXecute，执行)：对文件而言，具有执行文件的权限；对目录了来说该用户具有进入目录的权限。