TOC link was missing a needed #. While I had the file open I fixed
other formatting issues (overlong lines, code snippets that
shouldn't have been pretty-printed). No changes to the page content.
I'll build and stage (see first comment for staged doc location) but
if it looks good I'll +2 and submit it myself.
bug: 26191770
Change-Id: I3c15ed3dfaa0762729f8d778d4aa828710c0eefa
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
Bug was filed for a missing </set> tag in a code snippet; turned out
to be because the angle brackets weren't escaped, so </set> was
interpreted as HTML.
While I had it open, fixed other formatting issues (over-long lines
in a code box, weird indenting of HTML). No semantic changes, just
formatting.
I'll build and stage (see first comment for stage location) but if
it builds and looks good, I'll go ahead and submit.
bug: 25709592
Change-Id: I0ac1e74a230175fcab62021c89884f9eeabb4f97
Per bug, we should not be telling people to use
android:windowContentTransitions to specify custom transitions;
instead, they should use android:windowActivityTransitions (which
is set to 'true' by default in the Material theme).
See first comment for doc stage location.
bug: 19440221
Change-Id: I35696c595a8424eab27d73b62835ddd79e3ca109
Per bug, noted that orderID is blank for test purchases made with
the sandbox. Added this note both in the "testing" page and in the
reference for INAPP_PURCHASE_DATA.orderId.
See first comment for doc stage location.
bug: 19609418
Change-Id: I74ab54fdf69eeb32d331ea5900dc7582d8150dfa
Per bug report, the provided code doesn't draw the reveal properly.
Corrected to use the Math.hypot function to calculate beginning and
ending sizes.
See first comment for doc stage location.
bug: 25805924
Change-Id: I1eb832983ae1790262cc4c8051473f0f32115566
Per bug, emphasized that if an app targets SDK 22 or lower, it uses
the install-time permissions model even if it's running on M.
However, also added the note that an M user can *revoke* an app's
permissions after install, which can cause unpredictable behavior.
See first comment for doc stage location.
bug: 25470298
Change-Id: Ia05a1f784595e75bf7b6835dbfdeffcd458f0022
Gap in existing docs; Project Structure dialog wasn't documented.
See first comment for doc stage location.
bug: 26028645
Change-Id: I1423fb1a193bf2a85f1829e7076a43df9cb8604c
Adding new Translations Editor studio help topic, and updating
TOC and index accordingly. Updated Studio Features topic to
point to new Translations Editor topic. Added new editor
screenshot. Additional fixes added based on reviews.
Bug: 25973544
Change-Id: I8f319cf6ec95f29f1cdb462efc6b3711ded6fdd8
This is a partial revert of http://ag/738523 , but not a full
revert because M apps that have gone through the WRITE_SETTINGS
route to obtain permission to change network state should
continue to have permission to do so.
Specifically:
1. Change the protection level of CHANGE_NETWORK_STATE back from
"signature|preinstalled|appop|pre23" to "normal". This allows
apps that declare CHANGE_NETWORK_STATE in their manifest to
acquire it, even if they target the M SDK or above.
2. Change the ConnectivityManager permission checks so that they
first check CHANGE_NETWORK_STATE, and then ask Settings
if the app has the WRITE_SETTINGS runtime permission.
3. Slightly simplify the code in the Settings provider code that
deals specifically with the ability to change network state.
4. Make the ConnectivityService permissions checks use the
ConnectivityManager code to avoid code duplication.
5. Update the ConnectivityManager public Javadoc to list both
CHANGE_NETWORK_STATE and WRITE_SETTINGS.
Bug: 21588539
Bug: 23597341
Change-Id: Ic06a26517c95f9ad94183f6d126fd0de45de346e
