We'd already noted this in the "new in Android 5.0" page but we
hadn't moved this into the base "permissions" pages. Added it, with
some usage recommendations from the bug.
Also fixed some formatting while I had the files open.
See first comment for doc stage location.
bug: 18143176
Change-Id: I9cc1a8865492ebf30c7a0f7c325669ded670933e
This undoes the automerger skip which occured in
commit e740c84dc32180214a7fd157105d6c18d30408ee and
replays it as a standard (NOT -s ours) merge.
Change-Id: If5a47be26f73d6a0735c425cd66310a3e2a89086
Initial pass at Network Security Config documentation, this also adds a
Security section to the list of topics which is currently just a stub.
Bug: 26931435
Change-Id: Iae0ec98a202ad3222b8f3ef39df77ecd2316504a
While checking the manifest for N permissions changes, I saw a
normal permission that had been added in M and not documented.
(The permission was added to AndroidManifest.xml, so it *was*
being listed in the android.Manifest javadoc.)
See first comment for doc stage location.
bug: 27222922
Change-Id: I5740fdb3da3cac37b15d87fe5f092d305c52449d
List of normal permissions had drifted from alphabetical order;
fixed.
See first comment for doc stage location.
Change-Id: I031d1142275c9fd53a2ce16fcd54fdcf206d03a7
Per bug b/26383626 , the FLASHLIGHT permission was never actually
used, and isn't checked by the new CameraManager.setTorchMode()
method. The permission has been removed from the manifest on
master; there's no reason to list it now in the list of normal
permissions.
See first comment for doc stage location.
bug: 26383626
Change-Id: I0c39dd5e1cdde1fc6a85759663b7e5ad669dc280
Just a missing period; I'll build (see first comment for stage
location) then if it looks good I'll submit.
bug: 26359756
Change-Id: I1f0619f23559abadacccc9a60d19aaf69713a6e2
Fixed a typo and also removed a couple of extra blank lines. I'll
build (to make sure I didn't break anything) then if it looks good
I'll self-+2 and commit.
bug: 26359706
Change-Id: Idc873ad774769819708c3d227d23e676a7fa1a90
The doc previously said that you need just the normal FLASHLIGHT
permission to turn on the flashlight. This was wrong in a couple of
ways: For the (deprecated) Camera API, you need CAMERA permission just
to get the Camera object (which you use to turn on the flash); for
the new Camera2 API, you don't need any permissions at all to turn
on "torch mode". So I've removed this example and replaced with a more
straightforward example of a normal permission (setting the time
zone).
I've filed a separate bug, b/26308110 , to update the FLASHLIGHT
permission docs (once I've confirmed the right update to make).
See first comment for doc stage location, but if the build is
okay I'll just go ahead and submit.
bug: 26104001
Change-Id: Ie0802b4818bd0ba4d3fd026e32620978827e50df
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
One hyperlink used the {@docRoot} tag even though it's a link to
a separate site (AOSP), so the link didn't work. Two other (internal)
links began with a slash instead of {@docRoot}, which kinda works
but isn't how we do things.
I'll build and test (and post the stage link in my first comment) but
if it looks good I'll go ahead and +2/merge it myself, since there
are no prose changes.
bug: 25755465
Change-Id: I11af855ed7a1e4a12ced7d0d7f6d5a4705c66811
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
