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, 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
Per request, noted that project templates use support library
objects, and explained that (e.g.) this means they can provide
material design features on older devices.
See first comment for doc stage locaton.
bug: 25973575
Change-Id: I9e21d4257583c03bbba5cfa309cbe6fe1f91e600
Adding basic info on Studio's support for data binding. In 1.x this
is limited to syntax highlighting, expression error flags, and Preview
support for defaults. Added link to tools attributes page.
Updated with recommendations from reviewers.
Bug: 25974303
Change-Id: I18d86208fd372e041b1dc0697e44e259fa1c9127
Editor page.
Removed "Dynamic Layout Preview" section from Studio index page.
Added Layout Editor tab to the "Tools Help" TOC.
Bugfix :25973267
Change-Id: I17726597d1d76c59718f2076a1a508dbd8f96350
Added description of new prorated seasonal subscription prices. Also
noted that free trials are now supported for seasonal subscriptions.
Per Z's request, also folded in a bugfix that had been waiting a
while.
See first comment for doc stage location.
bug: 25756808
bug: 14070005
Change-Id: Id43ed7bd6f84ec0ba9a05c4202fc2585c7fd6a22
Bug: b/24062075
This changes Work Policy Controller to Device Policy Controller. This also fixes typo reported in
https://b.corp.google.com/issues/23627319#comment2.
Change-Id: I9f38e392720872ee217d4e1dc976dbd7356e5025
Per bug report, clarified when an app needs GET_ACCOUNTS permission
to read the current account's information.
Along the same lines, clarified that the CONTACTS permissions group
regulates permissions for all accounts and contacts on the device, not
just the user's contact info (since GET_ACCOUNTS is in CONTACTS, and,
as noted, GET_ACCOUNTS applies to other users' info).
See first comment for doc stage location.
bug: 23589012
Change-Id: Ia87565936787dd85daedfb641883e7cbf778f2bd
