1
我怀疑我收到的一些错误报告(无法打开数据库,或由Context.getFilesDir()返回null)是由于底层的Linux权限不足;我见过一些参考文献,说有时android应用程序会进入坏的状态,应用程序的数据目录的所有者与分配给应用程序的UID不同。比较来自Android PackageManager的uid与来自ls的uid -l
所以工作设备上我用
adb shell
run-as my.package.name
ls -lR
,并得到u0_a29的UID。 我也跑这个代码片段:
PackageManager pm = getPackageManager();
ApplicationInfo packageInfo = pm.getApplicationInfo("my.package.name", 0);
Log.d("UIDTEST", "Package " + packageInfo.packageName +
" has uid " + packageInfo.uid);
,并得到了10029.
一个UID据推测,这些其实都是相同的值,看到应用程序是如何工作的这个设备上,但有什么实际关系在这里?是“取最后2个字符,放弃其余的,并根据你要走的路向前加u0_a还是100”?因为这看起来很奇怪。 a29看起来像十六进制,但当然只有2601。我想在将代码部署到现场之前了解此情况,以尝试从破损的安装中捕获此信息。
这使得更有意义。谢谢! – benkc
顺便说一句,这是支持多用户的设备上的新格式。 'u0'代表'user 0'(第一个/默认用户),'a29'代表'app 29'。至于UID,Android会将10000('AID_USER')与用户ID(*不与UID相同!)相乘并与应用程序UID进行或运算,以获得应用程序执行的有效UID。对于默认用户以外的用户,您将得到类似于u10_a3 - > 1010003(10000 * 10 + 3)的内容。 –