There are a couple of 'signature' permissions that have a special
user-authorization process; mentioned them and put in a link to their
reference docs.
The reference docs for those methods is being updated in a separate
CL, http://ag/784299
See first comment for doc stage location.
bug: 24673125
Change-Id: I4f17784b570d6154482e3fe965bd2de1043babb6
Updates the docs to reflect the new Android M "runtime permissions"
model. (There's also a new training class, in a separate CL:
http://ag/762246 ) Removed the M Preview permissions page (but didn't
remove all references to it--Q will do that in a separate CL).
See first comment for doc stage location.
bug: 23725768
Change-Id: Iafb801f1188d1bb6b66ac19c9c1dfce0114df271
* revise to the Compatibility doc, put it in Intro
* put Permissions in Intro
* put App Fundamentals in Intro
* move Manifest docs to the top of side nav tree
* move App Resources above UI
Will perform another fix to the Best Practices section
later to deprecate some docs there and point to Training instead
Change-Id: I88a8f94167ba15e97eb3bbbc08fd82dd82498e4b
Assert plainly that Dalvik is not a boundary.
Certificates are for distinction, not "fake trustworthiness through
verifying cheap identities".
Clarify that UID + GID are what the kernel bases its protection on, not PID.
This is a fuzzy distinction on Android since (apart from sharedUserId and
magical system processes) there is a 1:1 mapping from process <-> UID. But
it's important to clarify what we mean.
Clarify up front about the staticness (staticity?) of permissions. It's
explained lower down, but experience shows people don't read that far down.
Get the rationale (bad UX --> bad security) right up top.
Change-Id: I403310668d7ba42e44239055cb480c086ef76cbc
