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
Use Thread.sleep instead of Object.wait which simplifies the example.
Also there is a tiny chance, that wait will be called with 0, which
blocks forever.
Change-Id: I4cf90a33089a64bdf802620350f76af08f15f721
(cherry picked from commit 77d8857ed58503669e0659989c02fb7f1ca936b4)
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
Fixed a reported typo (see bug), and while I had the file open, fixed
a few other typos and formatting problems.
I'll go ahead and build and stage this (see first comment for stage
location) to make sure I didn't break anything, but if it looks okay
I'll +2 it myself and submit it.
bug: 26356168
Change-Id: I57727cecd671ab877c0da27e487fa058d95914c5
Doc had said that users have to grant all permissions at install time
(which was misleading--users don't have to grant normal permissions--
and wrong if app and device use runtime permissions).
Changed the text to just say that the user needs to explicitly grant
"these permissions" (the permissions being talked about are all
dangerous), and pointed the reader to the Permissions training class.
I'll build and stage, but since it's a one-sentence fix I'll go ahead
and submit if it looks good.
bug: 25412683
Change-Id: Idc17828f2958d4f8900d29e564c05c54bf3ce753
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
Docs were slightly contradictory on when clients should unbind.
Changed a few sections to point to one "source of truth" section
that explains the appropriate times to call unbindService().
Updated with corrections to issues found by Andrew and Dave.
Bug: 8135078
Change-Id: If8afb998cbd2efceef075ee6633cf0744c50d1df
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
- Clarify hardware.camera feature being only for the back camera
- Clarify what setting a CaptureRequest field to null does
- Use preCorrectionActiveArray instead of activeArray in list of
possible raw output sizes
- Clarify length of GPS processing field for camera1 API
Bug: 24540625
Bug: 23908116
Bug: 23051627
Bug: 17345901
Change-Id: Iaf11fdf626268cf30f66b3628153ec3ac770c4f4
Docs had incorrectly said the element was named
<uses-permission-sdk23> (missing a hyphen in sdk-23). Fixing all
references to that element, and renaming the reference page
accordingly. A separate CL sets up a redirect from the old page
name to the new one.
See first comment for doc stage location.
Change-Id: I6e675e03f87851d36465a8fdf3de730de524c4a8
bug: 25346975
Removed the now-obsolete ActionBar API guide; it's been
superseded by the AppBar training class
(http://developer.android.com/training/appbar/ )
Changed the most important ActionBar links and references to point to
the AppBar docs (or some other appropriate page).
A separate CL will set up redirects from the ActionBar API guide.
See first comment for doc stage location.
bug: 25194804
Change-Id: I0859ea1712971fcf2f6cf131b2a5221b5bf3ea44
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
