displayId can be specified as a part of ActivityOptions.
We will look for a valid stack on the specified display, starting
from the topmost one. If no valid stack is found, new dynamic stack
can be created on external display.
Launch stack and display id can't be set at the same time, otherwise
exception will be thrown.
Test: ActivityManagerDisplayTests
Test: #testLaunchActivityOnSecondaryDisplay
Test: #testConsequentLaunchActivity
Test: #testConsequentLaunchActivityFromSecondaryDisplay
Test: #testLaunchActivityFromAppToSecondaryDisplay
Change-Id: I8a202bc076319e23948d81b99a2c68d7b733b5e4
Allow DO to bind service of PO in managed profile and vice versa.
DO and PO must be the same package.
Bug: 31895999
Change-Id: I3ce2943aebd1249401d5814757a0ce25b9f85279
Test: cts-tradefed run cts --module DevicePolicyManager --test com.android.cts.devicepolicy.CorpOwnedManagedProfileTest
So far AutoFillService only received the assist data from framework; in
this CL, it also offers a method where the auto-fill provider can send
the auto-fill data back to framework.
The workflow is:
- AFMSI calls a new AM method (requestAutoFillData(), instead
of requestAssistContextExtras()).
- The assist receiver is located in the app, not on system service.
- AM uses a new request type (ASSIST_CONTEXT_AUTOFILL) to request the
assist data to the activity.
- ViewStructure has a new setAutoFillId() method which is used to set an
unique id for the view.
- View uses the accessibility id to implement the auto-fill id.
- When the activity fullfills the request, it creates an IAutoFillCallback
remote object - that will be used to set the auto-fill fields - and
returns it in the assist bundle (using the
VoiceInteractionSession.KEY_AUTO_FILL_CALLBACK key).
- The app-visible AutoFillService class offers an onFillRequest() method,
which contains the assist data and a FillCallback used to handle it.
BUG: 31001899
Test: manually built and ran it
Change-Id: I3d208c14e81022dc96dd03f38bbe25a778b24a67
In some situations it would be useful if the application can give a
hint that the user is not likely to want the IME to update
personalized data such as typing history and personalized language
model based on what the user typed the input area.
Typical use cases are:
* When the application is in a special mode, where user's activities
are expected to be not recorded in the application's history.
Some web browsers and chat applications may have this kind of
modes.
* When storing typing history does not make much sense. Specifying
this flag in typing games may help to avoid typing history from
being filled up with words that the user is less likely to type
in their daily life. Another example is that when the application
already knows that the expected input is not a valid word (e.g.
a promotion code that is not a valid word in any natural language).
Applications need to be aware that the flag is not a guarantee, and
some IMEs may not respect it.
Since this is basically about the general behavior that can be
combined with any of type of input types, this CL uses
EditorInfo.imeOptions instead of EditorInfo.inputType.
Also so far it look OK to do nothing in EditorInfo#makeCompatible()
regarding this flag because 1) this bit (0x1000000) has never been
used and 2) it is less likely that just passing that bit to an IME
that do not know about this bit causes any issue.
Bug: 28157942
Test: compile only as this is just a hint and OS does nothing
Change-Id: Ibf5ac3d2b8f39542baf2635c0cadbe242b059f81
Respect TelephonyManager's subId when listening to phone state
TelecomManager perfers to use a PhoneAccountHandle to represent a
account but TelephonyManager prefers subscription IDs.
This CL added createForPhoneAccountHandle() in TelephonyManager so
telephony values can be queried from it.
Currently the ServiceState can be retrieved through registering a
PhoneStatelistener, but it is a callback which the handler cannot be
specified.
getServiceState() is added to allow the ServiceState to be polled.
While TelphonyManager has createForSubscriptionId(), listen() does not
respect the subId on the manager created from it, and will always use
the hidden subId on the listener, which is always the default subId
through public API.
After this CL, the default subId on the listener will null.
TelephonyManager use its' own subId if the listener does not set the
subId to something else.
Bug: 32637799
Bug: 32414216
Test: cts-tradefed run cts-dev --module CtsTelephonyTestCases
Change-Id: I9995e4da1573cf1f6b6e4acf2daf7a538fb60d5f
When a calling InCallService attempts to use the setCamera API on the
VideoCall, Telecom will perform a permission check to ensure that the
caller has the correct camera permission and passes the app-ops camera
check. A failure to set the camera will result in a callback via the
call session event API.
This got a little messy as the app ops package name needs to come from the
InCallService, and handler usage in the VideoProvider API means we had to
pass around the uid/pid of the caller, obtained before we trampoline onto
the handler.
Test: Unit tests added, manual testing performed.
Bug: 32747443
Change-Id: I555a04f9c3fb45e60bb811f64ba855ccf2e3b0e2
Rename ranker to assistant and make some of the methods public.
Delete the ext services ranker and restore the listener-type
lifecycle to the assistant.
Test: manual. add a notification assistant and verify it gets
assistant and listener callbacks.
Change-Id: Ia3406c8c14d923426c1b8a6d8b5187efe64c31c3
Half floats (often called fp16) are commonly used to store floating
point data efficiently without having to use lossy compression schemes.
Half floats are commonly used in the following cases:
- Wide gamut colors
- Meshes (OpenGL and Vulkan)
- HDR images/textures
- Lookup tables as textures (OpenGL and Vulkan), particularly
in physically-based renderers
- Maching learning/compute
OpenGL and Renderscript both provide Java language APIs that accept
half floats but the platform offers no support to create fp16 values
from fp32 data. The Half class is an IEEE 754 compliant implementation
of half floats that can be used to feed OpenGL and Renderscript properly
encoded values. A comprehensive series of test is also added to CTS.
Test: cts-tradefed run singleCommand cts-dev --module CtsUtilTestCases --test android.util.cts.HalfTest
Bug: 29940137
Change-Id: I908bde7b3c6f65f7a24e0ab5652be4d16cc0358d
This CL provides the initial, skeleton implementation of the Auto-Fill
Framework classes:
- Defines the system service and app-based
AIDL (IAutoFillManagerService.aidl and IAutoFillService.aidl respectively).
- Defines the 'adb shell cmd' interface.
- Defines the permission required to access the service.
- Registers the service on SystemServer.
- Adds the code to bind the app-specified service to system_server.
- Defines the service class (AutoFillService) required by providers.
- Implements the initial startSession() method.
This is still a very early, "work-in-progress" change:
- It has many TODOs.
- It does not have unit or CTS tests yet.
- It does not provide a callback method to auto-fill the fields.
- In fact, it has a lot of TODOs.
Despite these adversities, it can be tested by following the steps
below:
1.Create an app with a service extending AutoFillService
2.Implement the onNewSession() method
3.In the manifest:
- Listen to android.service.autofill.AutoFillService intents.
- Require the android.permission.BIND_AUTO_FILL permission.
4.Explicitly set the app as an autofill-service by running:
adb shell settings put secure auto_fill_service MY_APP/.MY_SERVICE
5.Start a session against the top activity:
adb shell cmd autofill start session
BUG: 31001899
Test: manually built and ran it
Change-Id: I00f4822159b31ddddba8f513e57c4474bc74eb89
This is the first swack at the new, 2-phase API. Adds the new methods
to the resolver service and makes the split name explicit on the
installer intent.
The 2nd phase will not yet be invoked; that's coming in a follow-on
change.
Bug: 25119046
Test: build & install the sample resolver and run 'adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d "https://www.tripadvisor.com/Tourism-g33020-San_Jose_California-Vacations.html"'
Change-Id: I2df6fa64d46f17a86a2e32b19417632c594fb10f
To do this, I had to fix the PROCESS_STATE_NONEXISTENT constant
to be the last value (instead of the special magical -1 value)
so it semantically matches the public importance constants. I
think this is better anyway.
Also this fixes a big problem in the implementation, where we
weren't keeping track of the last proc state per uid...! Duh.
Test: manually ran testUidImportanceListener
Change-Id: Ie3008f824446089840f896885e6033472abb065e
Changed the permission for registerUidObserver to be
PACKAGE_USAGE_STATS, which better matches the semantics of this
API and is accessible to system apps.
Test: Added testUidImportanceListener()
Change-Id: Ib47d02bd654fbe399a9c92550c89ecbd38f928dc
Also remove comments that disallow folders in search results.
Test: It builds.
Bug: 30948740
Bug: 32512923
Change-Id: I72706b69163aa98ee9568939e09e5048b6e8f9f8
Adding companion PhoneAccount capability which is used to indicate when a
PhoneAccount supports video calling. That is, whether it can potentially
make video calls, but not necessarily at the current time.
This is an often requested OEM enhancement which is used to drive UX (e.g.
imagine a video calling icon showing up if the device supports video, but
only being enabled when the device is in range of a VT capable tower).
See bug for reference to design doc.
Bug: 27328615
Change-Id: I08fc18950e6d35a8a7df47ce37aa2326624b9fd3
