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
The example code for openDevice() was missing a close bracket.
Bug: 25283941
Change-Id: I8fac6a6dee2393125ad4e057cb857fe21e43b491
Signed-off-by: Phil Burk <philburk@google.com>
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
The code snippet was copied straight from the MediaBrowserService
sample app. Since the code snippet consisted almost entirely of
calls to *other* methods in that sample app, the snippet wasn't
very helpful--and it wouldn't be helpful to add a lot of verbiage
explaining the sample app. So instead, I made the code more generic
(e.g. comments saying "You need to write code to check for XYZ")
followed by a link to the sample app.
Fixed other miscellaneous problems in the code snippets while we had
the file open.
See first comment for doc stage location.
bug: 20008288
Change-Id: Ic080ebffcc43e332ec3335b730c07ef5f8b64fa9
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)
