В чем разница между системными приложениями и привилегированными приложениями на Android?
Итак, в 4.3 появилась концепция системных приложений. APK, помещенные в /system/app
, получили системные привилегии. Начиная с 4.4, существует новая концепция "привилегированного приложения". Привилегированные приложения хранятся в каталоге /system/priv-app
и, похоже, рассматриваются по-разному. Если вы посмотрите в исходном коде AOSP, в разделе PackageManagerService
вы увидите новые методы, такие как
static boolean locationIsPrivileged(File path) {
try {
final String privilegedAppDir = new File(Environment.getRootDirectory(), "priv-app")
.getCanonicalPath();
return path.getCanonicalPath().startsWith(privilegedAppDir);
} catch (IOException e) {
Slog.e(TAG, "Unable to access code path " + path);
}
return false;
}
Итак, вот пример ситуации, когда они различаются.
public final void addActivity(PackageParser.Activity a, String type) {
...
if (!systemApp && intent.getPriority() > 0 && "activity".equals(type)) {
intent.setPriority(0);
Log.w(TAG, "Package " + a.info.applicationInfo.packageName + " has activity "
+ a.className + " with priority > 0, forcing to 0");
}
...
Это влияет на приоритет любых действий, которые не определены как системные приложения. Это, по-видимому, означает, что вы не можете добавить активность в диспетчер пакетов, приоритет которого выше 0, если вы не системное приложение. Это означает, что не предотвращает привилегированные приложения, насколько я могу судить (здесь много логики, возможно, я ошибаюсь).
Мой вопрос в том, что именно это подразумевает? Если мое приложение имеет привилегию, но не систему, какая разница? В PackageManagerService
вы можете найти разные вещи, которые различаются между системными и привилегированными приложениями, они не совсем одинаковы. Для привилегированных приложений должна существовать какая-то идеология, иначе они только что сказали бы:
if locationIsPrivileged: app.flags |= FLAG_SYSTEM
и было сделано с ним. Это новая концепция, и я думаю, было бы важно знать разницу между этими приложениями для тех, кто занимается разработкой AOSP с 4.4.
Ответы
Ответ 1
Итак, после некоторого копания выяснилось, что приложения в приватном приложении имеют право на системные разрешения, так же, как старые приложения, которые раньше имели право требовать разрешения системы, находясь в системном приложении. Единственная официальная документация Google, которую я мог найти, появилась в виде сообщения о фиксации:
Commit hash: ccbf84f44c9e6a5ed3c08673614826bb237afc54
Некоторые системные приложения больше, чем другие.
"signatureOrSystem" разрешений больше не доступны для всех приложений находясь в системном разделе. Вместо этого есть новый /system/priv -app, и только приложения, чьи APK находятся в этом директориям разрешено использовать разрешения signatureOrSystem без обмен сертификатом платформы. Это уменьшит площадь поверхности для возможные подвиги системных приложений, чтобы попытаться получить доступ к разрешенным операциям.
Флаг ApplicationInfo.FLAG_SYSTEM продолжает означать, что он говорит в документации: это указывает, что приложение apk было вложенных в/системный раздел. Новый скрытый флаг FLAG_PRIVILEGED, который отражает фактическое право доступа к этим разрешения.
Ответ 2
мое обследование было, у priv-app есть права на root.
предположим, что если вы установите корневое приложение в system/app, ему все равно потребуется supersu для предоставления root.
Но если вы устанавливаете одно и то же внедренное приложение в систему /priv -app, вам вообще не нужен суперсу.
Я наблюдал это, экспериментируя с ромом, чистя все китайские приложения n, устанавливая adaway, титан и т.д.
Ответ 3
Из того, что я красновато в Интернете, приватное приложение используется только для приложений Google. Если вам все еще нужно запускать приложения с системными правами, вы должны продолжать использовать /system/app. Метод, который вы публикуете в своих вопросах, фактически используется Google Apps!