Improved descriptions of the "name" attribute of the <application>
element, which appears within an Android app's <manifest> element in
its manifest file. Also clarified connection between this attribute
and custom subclasses of the Application class.
Bug: 1232595
Change-Id: I79b6bd31224c7669b5dc509914a01ead84a049dc
Abandoned-Change-Id: Icee66f6b8df55c7fad414b4c19939a483dc7a165
element.
Several files associated with a future CL contain extra whitespace.
I've made a separate CL here to avoid inflating the "changed lines"
count within this future CL.
Change-Id: Ie8199abd2a61b77d0fb349435983050e0e06afc7
Abandoned-Change-Id: I92f75ba0ef08e10210434f824fd99caee3703b5e
Changed word within "Process Lifecycle" section, near bottom of
Activity class overview.
Bug: 24561563
Change-Id: I4c4196a656b6ad3e412ed45382fcefc984fe9892
A comment didn't end with a period; since the comment was
being used as the summary for a Javadoc table, and included
documentation was being used as the details Javadoc comment, the
lack of a period was messing up the Javadoc formatting
( https://screenshot.googleplex.com/4cp0QHV35iW )
See first comment for doc stage location.
bug: 27130226
Change-Id: I907ffc6efa4148e98a3c35b6d03c85f50103c23a
bugs: 26695226, 26695390
b/26695226: Fix the typo
b/26695390: Work-around the failing heuristic described in b/26695390 by adding
periods to terminate lines when we want the Javadoc parser to
stop parsing the sentence.
Change-Id: Ibf972d50157b693b695f0dd3bda9c7b5976a93de
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 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
- 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
Edit XML comments to note that GET_ACCOUNTS permission is 'dangerous',
not 'normal'. Made a couple of other Javadoc fixes while I had the
file open (summary sentences that were badly formatted, messing up the
Javadoc summary tables). NO CHANGES outside of XML comments.
See first comment for doc stage location.
bug: 25630412
Change-Id: Ic5f80b9f99e283dcf2f1cb9d2ab4a38138ec66e6
The javadoc for CameraManager.AvailabilityCallback was missing an "#".
This causes the link to registerAvailabilityCallback not being generated
correctly.
Once the "#" was added the link shows up correctly.
Change-Id: I3da3aa737a6af487f117eccbeee5c682c003b7e2
Bug b/24993310 flagged an error in the code sample, and while I had
it open, I revised it to be more like the code snippet in the
permissions training doc (which Svet approved).
See first comment for doc stage location.
bug: 24993310
Change-Id: I65336c70e086b06e28816ba8acc6435640178f9c
Updated reference to note that SYSTEM_ALERT_WINDOW is now "signature"
instead of "dangerous". (The Manifest.permission class and javadoc
is automatically generated from Manifest.xml.)
Also clarified how an app can request SYSTEM_ALERT_WINDOW and
WRITE_SETTINGS privileges (it's different than for ordinary
'dangerous' permissions).
See first comment for doc stage location.
bug: 24673125
Change-Id: Id5908b6cc8c8ea3d6901f245cd35c771bdd2eb87
Update storage related docs on Context to be consistent, and to call
out relevant Environment methods. Start calling it "shared" storage,
and only mention external for historical reasons. Mention that there
isn't much benefit to using emulated storage over private data
directories to help guide developers to safer locations.
Point out which paths can change over time, so developers know to
only persist relative paths.
Update Environment docs to reflect how they behave for the new
class of adopted storage devices.
Bug: 24251945
Change-Id: Ie5ab337649b4740dfd7594997bbb19c4969cfd2f
(cherry picked from commit 59d28dc82000b1696ed9ef7ef2c0d7fbb2834100)
Previously, when CHANGE_NETWORK_STATE's protection level was raised to
signature from normal, the documentation was not changed. This CL
addresses the documentation to reflect the correct protection level.
Change-Id: I0a4d2fcef5f30c58b38250865543e72b5eb1ab06
(cherry picked from commit 369b7ca4fbe6a635344f43845a82da25ececa0e4)
