Provide a way for views to signal that they would prefer not
to have their parents scroll or otherwise rearrange when they
request focus to try to show the full focused view to the user.
In some cases this can be disruptive to the UX.
As of now, framework views do not respect this hint and custom
views such as those found in currently deployed support libs
don't either. The policy is left open to ViewParent subclasses
that implement requestChildFocus.
Bug 30256922
Change-Id: I55194de888fe2b8129be9a9aa21aa5e18cbb8296
starting a shortcut.
- Also add API surface to support launching multiple intents
- Also add SM.isRateLimitingActive() which was supposed to be
added but was not due to a bad rebase.
Bug 30218829
Change-Id: I82d60ec0df1e2b889538705f9f8870ee727dd55d
These methods were never meant to be public. Instead, developers
can use Context#createConfigurationContext().
Bug:30088019
Bug:29999297
Change-Id: I2b864136163deda0af99fa3bfe9ef4ee1077341a
This patch adds lifetime durations of DhcpClient states to
DhcpClientEvents.
To record the duration of a state, the event is now recorded when the
DhcpClient state machine exits that state.
In addition this patch removes event logging of StoppedState,
DhcpState and DhcpHaveLeaseState.
Change-Id: Ibd37b5e3070f35113b6b45942b1e1ff19c27a90b
This reverts commit c4b8f36de5523366e354fc01b6cba81ad72f6423.
Having InputContentInfo#requestPermission() should not hurt developers,
but we can polish the behavior in a subsequent CL without changing
the API.
Bug: 29450031
Bug: 29892936
Change-Id: I1b43c19417b643d0c269af860db2d309b73a90d5
Adds a new API that enables device-specific scheduler optimizations for
latency-sensitive VR threads.
BUG: 29163534
Change-Id: I58d7be0eb266eca452c804cd07004784fb7daf2b
It turns out that requiring editor authors to call
InputContentInfo#requestPermission() as needed is just confusing and can
cause compatibility issues, because if an editor author forgot to call
that method then there would be no way for IME developers to prevent
permission denial except for relaxing the default permission of the
ContentProvider just because of such an application. This is not what we
want to see.
My conclusion is that the system should automatically call
InputContentInfo#requestPermission() (or do any equivalent operation)
when InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION is
specified, like we have done in Context#startActivity().
With this CL, the system automatically grants a temporary URI permission
to the target application when the IME calls
InputConnection#commitContent() with
InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION, and the
temporary permission will be revoked by any of the following events:
- InputContentInfo#releasePermission() is explicitly called by the
target application.
- The target application returned false in
InputConnection#commitContent().
- All the InputContentInfo instances copied from the original one are
GC-ed.
Bug: 29450031
Bug: 29892936
Change-Id: I37fb744e4d3d1c59177fb0a9be4ef5c325c9a39f
This patch defines a new android.net.metrics.RaEvent class carrying
lifetime values contained in RA packets. RaEvent are recorded when
ApfFilter processes a new RA for which there is no match.
Example:
ConnectivityMetricsEvent(15:39:39.808, 0, 0): RaEvent(lifetimes: router=3600s, prefix_valid=2592000s, prefix_preferred=604800s, route_info=-1s, dnssl=-1s, rdnss=3600s)
Change-Id: Ia28652e03ed442d5f2a686ef5b3fafbcb77c503a
This patch adds a new ApfStats event class that counts RA packet
reception statistics on the RA listener thread of ApfFilter and reports
the maximum program size advertised by hardware.
Statistics are gathered for the lifetime of a network with APF
capabilities and uploaded at network teardown when the listener thread
exits.
Example event:
ConnectivityMetricsEvent(15:44:23.741, 0, 0): ApfStats(284945ms 2048B RA: 2 received, 0 matching, 0 ignored, 0 expired, 0 parse errors, 2 program updates)
Bug: 28204408
Change-Id: Id2eaafdca97f61152a4b66d06061c971bc0aba4c
1. removing deprecation for setExtras on Connection/Conference as these
have legitimate use-cases going forward.
2. Expanded documentation on Call.Callback class to clarify how it is
expected to be used.
3. Updated Callback#onConnectionEvent callback docs to clarify its usage.
4. Expanded Call#sendCallEvent docs to clarify expected namespacing of
call event keys and extras keys, as well as clarification about backwards
compatibility and expectations of ConnectionServices.
5. Standardized the "invoked" vs "notifies" language in the Conference
docs.
6. Clarified how Connection callbacks from Telecom should be implemented.
7. Added Bundle parameter expectations for pre-defined connection events.
8. Documented capabilities and properties toString methods.
9. Documented expectations for onCallEvent method.
10. Expanded documentation for sendConnectionEvent method to clarify
namespacing, use cases, etc.
Bug: 29759275
Bug: 29759954
Bug: 29759773
Change-Id: Ib8c983af4dbbfee68edb60937b268e2c1a9b5e64
Add an API to query if the calling app is running
in a demo user sandbox. This allows apps to customize
the starting experience to a potential customer.
Change-Id: I50e40f9a8c66da4b5672c1dc64606d7bedba3f8c
Fixes: 29833923
A notification is posted when the system storage gets too low.
Currently, it redirects into the Storage Settings. Instead,
it should redirect into the Deletion Helper to directly let the
user clear out their storage.
Bug: 29437277
Change-Id: I4e35adf300d5e479d4171f1e6f090f2a757400f2
Used to inform listeners when a connection can or cannot be part of a
conference. Used to inform the conference controller so that it can
recalculate the conferencable connections.
Adding carrier config for carrier requirement.
Bug: 29059073
Change-Id: Iab028fd44d87c8dc2bbbe8bba7ba9ccdc223fe51
It turns out that we can let the system to call
InputMethodService#exposeContent(InputContentInfo, EditorInfo), which
added in my previous CL [1], during the IME is calling
InputConnection#commitContent() as follows.
[IME]
InputContentInfo contentInfo = new InputContentInfo(
contentUri,
new ClipDescription(description, new String[]{mimeType}),
linkUrl);
getCurrentInputConnection().commitContent(
inputContentInfo,
InputConnection.INPUT_CONTENT_GRANT_READ_URI_PERMISSION,
null);
[App]
try {
contentInfo.requestPermission();
// Load inputContentInfo.getContentUri() here.
} finally {
contentInfo.releasePermission();
}
This gives us flexibility to let InputConnection#commitContent() do all
the magic for IME developers like other APIs such as
Context#startActivity(), rather than asking them to call one more API to
grant a temporary URI permission like a scenario where
Context#grantUriPermission() is used.
[1]: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
25e0813e6eb6315b1016db805fa9b791b4ae5cc2
Bug: 29450031
Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
Adding two new carrier config options:
1. treat_downgraded_video_calls_as_video_calls_bool - when there is an ongoing
call which was previously a video call (or is currently video call), some
carriers require that this is treated as if it is a video call for
telephony logic such as in (2).
2. drop_video_call_when_answering_audio_call_bool - if the user is in an
active video call (see (1)) over wifi, and an incoming audio call comes in,
when this carrier config option is "TRUE", the video call will be dropped
when the audio call is answered.
Adding new connection extra to indicate to the dialer app that answering
a ringing call will cause the current active video call to drop.
Bug: 29275420
Change-Id: Ied5dbabc8ff09045ba41c5eba2136adad10db80e
