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
- 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
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 59d28dc820)
To help MediaProvider uniquely identify storage devices, pass through
the UUID of the underlying private storage volume.
Bug: 23329611
Change-Id: I22ee7ea98fcb208d7797310acb3396a3f074f09b
Requests without NET_CAPABILITIES_INTERNET and just the default network
capabilities should not be marked restricted. Without this fix apps
can hit permissions exceptions if they inadvertently make requests
without NET_CAPABILITIES_INTERNET.
Bug:23164917
Change-Id: I4c7136821315bcb05dfc42ffbc505a5d4f6109e6
...from Camera360 to Hangouts }
In the short URI toString, include a small summary of the ClipData (instead
of just saying it has a clip data). This makes it a lot easier to understand
what is happening when you look at the log of activity starts.
Also separate out the activity manager dump of URI permission grants from
its dump of providers, so it is easy to just look at that state.
Change-Id: I68093d9f279944e1aa9a29347075f237f4f55ed3
..in link-opening behavior. If a candidate is marked as "ask
every time," then the user is guaranteed to get a disambiguation
prompt including that candidate even when some other candidate
app is in the "always prefer this over a browser" state.
Bug 23147746
Change-Id: I904d8697a992b3f16f32b1c1b49c2bf9424c7137
The platform grants runtime permissions by default to apps on the
system image that provide core device use cases which a user expects
to work out-of-the-box. We are now adding a test to ensure that
OEMs cannot pregrant premissions on non approved components.
bug:23043018
Change-Id: Id76717cce0ee59678956bd0be347d3c045fe4c51
When long pressing on an empty Text field with the system language set
to RTL, the "paste" popup was not showing up.
The Floating Toolbar requires a content rect to determine where the
text is and place itself close to it. In the case of an empty field,
we create a "fake" content rect by taking the placement of the cursor
+1 pixel to the right. In RTL languages, this +1 causes the content
rect to be considered off the bounds of the view, as the cursor is
aligned to the right, and hence the Floating Toolbar is hidden.
After making the rect a 0 width rect, we ran into the issue that
it was considered out of bounds due to the calculation ignoring rects
that simply touch the edge of the view's bounds.
BUG: 22540083
Change-Id: I29c79b701f586970b2611178233eff082b802ec1
Mostly due to no standard stream configurations being defined,
and for the correct overrides for DEPTH_POINT_CLOUD format.
Bug: 20537722
Change-Id: I8a18f5f68697a09dcc4d7555e51728193fe7f333
... by never rebasing the theme. We don't need to do this unless the
system theme is configuration-dependent, which it is not currently.
Bug: 22943781
Change-Id: I96e695441543379e4d5fdf3cc6f18d9e6cf953b4
We weren't closing the ZipFiles created in WebViewFactory to check
inside APKs - use try-with-resources to get them closed automatically.
Bug: 23072621
Change-Id: I11c6b77e960a7d240d19d22240cac177b6ba27b2
We now have a new whitelist you can put apps in, which
opts them out of the old battery saver mode and new app idle,
but doesn't keep them from going in to doze. This is for a few
special cases that we had previously whitelisted for battery saver,
and inherited to the new modes... ultimately we should figure out
how to get these apps out of the whitelist completely, but this
will help for now.
Apps in this new whitelist are not shown in the UI, because they
are still significantly restricted by not being able to operate
normally in doze. This also means they are still visible in the
list of all apps for the user to be able to put them on/off the
complete whitelist if that is what they really want.
In the course of doing this, I needed to clean up code in the
network policy manager to better separate management of the
two firewall rules that now have different whitelists applied
to them. This also hopefully just generally simplifies and cleans
up that code. Hopefully!
Change-Id: I92e15f2f85899571dd8b049b5e3eb1354f55f353
