AOSP Privileged vs System app

Así que en 4.3 había un concepto de aplicaciones del Sistema. Los apks que se colocaron en System / app recibieron privilegios del sistema. A partir de 4.4, hay un nuevo concepto de aplicación Privileged. Las aplicaciones privilegiadas se almacenan en el sistema / priv-app y parecen ser tratadas de manera diferente. Si busca en el código fuente de AOSP, bajo PackageManagerService, verá nuevos métodos como

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; } 

Así que aquí hay un ejemplo de una situación en la que estos son diferentes.

 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"); } ... 

Esto afecta a la prioridad de cualquier actividad que no se define como aplicaciones del sistema. Esto parece implicar que no puede agregar una actividad al gestor de paquetes cuya prioridad es mayor que 0, a menos que sea una aplicación del sistema. Esto no impide aplicaciones privilegiadas en la medida de lo que puedo decir (hay una gran cantidad de lógica aquí, puede que esté equivocado.)

Mi pregunta es ¿qué implica exactamente esto? Si mi aplicación es privilegiada, pero no el sistema, ¿qué diferencia hará eso? En PackageManagerService puede encontrar varias cosas que difieren entre el sistema y las aplicaciones privilegiadas, no son exactamente los mismos. Debería haber algún tipo de ideología detrás de las aplicaciones privilegiadas, de lo contrario, simplemente habrían dicho:

 if locationIsPrivileged: app.flags |= FLAG_SYSTEM 

Y se ha hecho con ella. Este es un nuevo concepto, y creo que sería importante saber la diferencia entre estos tipos de aplicaciones para cualquier persona que esté haciendo el desarrollo de AOSP a partir de 4.4.

Así que después de algunas excavaciones, está claro que las aplicaciones en priv-app son aptas para los permisos del sistema, de la misma manera que las aplicaciones usadas solían ser elegibles para reclamar los permisos del sistema al estar en la aplicación del sistema. La única documentación oficial de Google que pude encontrar en esto vino en forma de un mensaje de confirmación: Commit hash: ccbf84f44c9e6a5ed3c08673614826bb237afc54

Algunas aplicaciones de sistema son más sistema que otras

Los permisos "signatureOrSystem" ya no están disponibles para todas las aplicaciones que residen en la partición / system. En su lugar, existe un nuevo directorio / system / priv-app, y sólo las aplicaciones cuyos APKs están en ese directorio se les permite usar los permisos de signatureOrSystem sin compartir el cert de la plataforma. Esto reducirá el área de superficie para posibles explotaciones de aplicaciones agrupadas en el sistema para intentar obtener acceso a las operaciones protegidas por permisos.

El indicador ApplicationInfo.FLAG_SYSTEM sigue indicando lo que dice en la documentación: indica que la aplicación apk se ha incluido en la partición / system. Se ha introducido una nueva bandera oculta FLAG_PRIVILEGED que refleja el derecho real de acceder a estos permisos.

Mi obesidad era, priv-app tiene permiso de root. Suponga que si u instalar una aplicación enraizada en el sistema / aplicación que todavía requiere supersu para conceder raíz. Pero si u instalar la misma aplicación enraizada en el sistema / priv-app no ​​necesita supersu en absoluto. He observado esto mientras experimentaba con una ROM, limpiando todas las aplicaciones chineese instalando adaway, titanio, etc.

De lo que estoy en rojo en la web, priv-app se utilizan sólo para las aplicaciones de google. Si todavía necesita ejecutar aplicaciones con permisos de sistema, debe continuar usando / system / app. El método que publicas en tus preguntas es, de hecho, utilizado por google apps!

  • Qué hacer con el error curl clone.bundle en AOSP repo sync
  • ¿Cómo generar automáticamente diff entre versiones de API?
  • Cómo sincronizar sólo Android 2.2 código froyo?
  • Android: ¿Cómo emparejar los dispositivos bluetooth de forma programática?
  • Error al cargar diccionario al modificar android LatinIME en Eclipse
  • Eliminar los paquetes no deseados de la fuente de Android descargada antes de la compilación
  • ¿Cómo agrego APKs en una compilación de AOSP?
  • ¿Por qué son abstractas estas funciones, dónde encontrar el cuerpo (aplicación específica) de ellas?
  • Creación de AOSP en un dispositivo personalizado
  • ¿Qué son los archivos ODEX en Android?
  • Modificación de la interfaz de usuario de la aplicación individual (teléfono, contactos) en ICS AOSP
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.