There were a number of Javadoc style problems in the
WifiNetworkSuggestion.Builder.build() docs, which caused some formatting
problems.
One specific problem worth noting: A {{ causes trouble at publish time,
because it looks like the start of a Django directive. But escaping the
{ -- e.g. { -- doesn't work, because the Javadoc compiler helpfully
escapes the *ampersand*, so the HTML output is "&#123", which
renders on the page as "{" instead of "{". So putting a space
between the two braces seems like the simplest solution.
No code changes here, just Javadoc comment fixes.
Tested by building the docs and staging to:
http://go/dac-stage/reference/android/net/wifi/WifiNetworkSuggestion.Builder#build
Screenshots (in case the stage gets overwritten):
https://screenshot.googleplex.com/o4p7efFGCbJ.png (1)
https://screenshot.googleplex.com/nkhEqU54LNb.png (2)
Bug: 128536865
Test: make ds-docs (then build & stage)
Change-Id: Ie04bc4dc517443a6899aba989beeb38b9299826e
The existing API RemoteInput.Source covers two scenarios for responding
to message notifications:
1. A user uses the 'reply' button and enters a response freely.
2. A user clicks a smart reply which is used as the response.
Before this CL the platform would notify the app of scenario nr. 1 in
the case where we use tap-to-edit smart replies (replies that can be
edited before being sent). With this CL we instead log scenario nr. 2
(since a smart reply was clicked).
Bug: 123407240
Test: use a test-app to ensure that a response created using smart
replies + tap-to-edit logs the correct @Source.
Change-Id: I3dc8169a3c440af106c4f244b72ddf7c9e450203
The logic is like:
1. If content description string with app name placeholder is available,
and we also have a app name, then we will use this string.
2. Otherwise, fallback to content description string without app
name placeholder.
Test: atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/
Test: Actually see the content description with app name is formatted
properly
BUG: 128541828
Change-Id: Iee1dc8d4a429d759d9ab3f4b84dc1ad13b698cdb
In TrustManager user state defaults to "locked", so previously
the profile would become locked after work challenge is enabled.
Test: manual
Bug: 121256032
Change-Id: Ic0f5b075b85ca66c28d51830b47ed015c10da45c
when user is removed.
For non system users, backup state is stored in both the user's own dir and the system dir.
When the user is removed, the user's own dir gets removed by the OS. This code change ensures
that the part of the user backup state which is in the system dir also gets removed.
Bug: 127650374
Test: atest -v CtsBackupHostTestCases:android.cts.backup.MultiUserBackupStateTest
Change-Id: I4ea252e8e6da608e36ec3ac335666923d88a8748
Inform ART about the location of the app's data directory when setting
up the process. This is part of an optimization that has ART cache
verification data into that directory.
Test: compiles, boots
Bug: 72131483
Change-Id: Ic80526b6ee383733eb5860e66f6c608109d838fb
With the new MediaProjection based flow for cast, we will have
a connected MediaRoute active at the same time as a MediaProjection
session. In order to deal with them correctly, we need to assume
in a few places that we have more than one active CastDevice. We
also consider all devices that are connected, regardless of whether
the given route is selected or not.
Test: Manual
Test: atest CastControllerImplTest
Test: atest SystemUITests
Bug: 128515798
Change-Id: Ie46798633f69c347ee32e0799d6cb23576122dd9
