Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a4)
After several attempts [1][2], this is our latest attempt to
gracefully ignore BadTokenException an IME that is being destroyed is
still handling pending showSoftInput() requests.
The point is that SoftInputWindow is a hidden API. This means that
instead of adding a bunch of try/catch blocks around mWindow.show() in
InputMethodService we can always override SoftInputWindow#show() to
inject our own code around mWindow.show().
With this CL, we can now fully track the internal lifecycle of
SoftInputWindow in SoftInputWindow#mWindowState. It enables us to
easily sort out cases like double fault cases discussed
in Bug 113159114, where showSoftInput() requests were queued multiple
times and still IMEs crash because what mWindow.show() throws for
the 2nd failure is IllegaStateException not BadTokenException.
[1] Id1e5f236f48c8ef01b7f157ba3f6e7ab2c26b135
6fcbb56290
[2] I2c21573cf972145ab08e66604cdb9344139a3f31
e4bbb1cc45
Fix: 113159114
Test: Manually verified IME switching scenario as follows.
1. Build and flush aosp_taimen-userdebug
2. make -j SoftKeyboard
3. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
4. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
5. Open the Dialer app and tap the top edit field.
6. Make sure that AOSP Keyboard is shown.
7. Tap the globe button on AOSP Keyboard.
8. Make sure that AOSP Keyboard is dismissed and SoftKeybaord is
shown.
9. Tap the globe button on SoftKeybaord.
10. Make sure that SoftKeybaord. is dismissed and AOSP Keyboard is
shown again.
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I1f51ed29df6b22b003ca285698e06b8f3ee5106a
For packages:
android.inputmethodservice
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I4b417b8257486fbdaa3b0f54a02ab70696d199e0
KeyboardView relies on deprecated Canvas#clipRect(Rect, Op.REPLACE).
This method is now unsupported and throws runtime exception.
Operations other than Difference and Intersect are unsupported.
This method call can be replaced by saving initial Canvas and calling
intersect operation of Canvas#clipRect(Rect).
Saving initial state can be achieved using Canvas.save() and
Canvas.restore().
Fixes: 79777033
Test: Manually verified with SoftKeyboard (which uses KeyboardView)
1. m SoftKeyboard
2. Set current keyboard to SoftKeyboard
3. SoftKeyboard runs fine
Test: Tested Canvas.getClipBounds() is consistent across save() &
.restore() operations
Change-Id: Id34c289f152b2ec06f37fffa9f940a909153447c
This is a follow up CL to our previous attempt [1] to make
InputMethodService#setBackDisposition() work and make sense.
Based on the feedback from several IME developers, we learned that
InputMethodService#setBackDisposition() is still confusing.
My conclusion is that trying to reuse existing flags was a mistake.
Here are the rationale for deprecating those two flags.
* BACK_DISPOSITION_WILL_NOT_DISMISS
This flag had never been used until we started using it in our
previous CL [1]. However, it turns out that what this flag means
is hard to understand because its JavaDoc only says
"This input method will not consume the back key."
To address the original goal of Bug 38513361, we can (and should)
introduce a new flag rather than reusing this confusing flag.
Deprecating this flag should have no impact because it had never
been used.
* BACK_DISPOSITION_WILL_DISMISS
On pre-P devices IME could abuse this flag to override the back
button to "dismiss" mode even after IME lost the focus. On the
other hand, as far as we know there is no good use case for this
flag. Hence rather than trying to fix such an abuse scenario, we
should just deprecate this flag.
Instead, a newly introduced flag BACK_DISPOSITION_ADJUST_NOTHING
should be sufficient to achieve the original goal of Bug 38513361.
This flag does not rely on the concept "dismiss" and key event
handling hence it would be much easier to maintain.
[1]: I99e7c413fe1a93f8d8cff897b5c5f0947690d2c0
3fecef119e
Fix: 74403102
Test: atest CtsInputMethodTestCases
Change-Id: I064209c40da79fffb2627e8f580818a793017b1f
d8d03a8e1b added new methods to
InputMethodService.
Allowing IME developers to override some of these methods would introduce
unnecessary complexity. Making these methods final makes sure developers
cannot inject some unexpected behavior when called by system.
Bug: 73701052
Test: atest InputMethodServiceTest
Test: atest CtsInputMethodServiceHostTestCases
Change-Id: I1af4ed05a0b7306d840a21129e921a57b4a5fc33
onWindowShown is more like it should called after mWindow.show()
in InputMethodService. Considering the compatibility problem, just
make its javadoc clearer to the IME developers rather than
change the calling order.
Bug: 72922821
Test: N/A
Change-Id: Ibfe20f40a65475f39c8e79d10e2c494e212cf054
Signed-off-by: tiansiming [田思明] <tiansiming@xiaomi.com>
InputMethodService.setBackDisposition() has been broken from a long
time. This is how setBackDisposition() is supposed to work
1. BACK_DISPOSITION_WILL_DISMISS:
When Keyboard is visible back button will show as down arrow (in
navigation bar) and tapping it will dismiss keyboard.
2. BACK_DISPOSITION_WILL_NOT_DISMISS:
When keyboard is visible, back button will be shown as BACK arrow and
tapping it will send the back event to current activity. If activity
doesn't handle onKeyDown() for back button, activity will finish and
keyboard will hide.
Note: backDisposition flags reset when finishInput() is called.
Bug: 38513361
Test: Manual with apk attached in bug
Test: atest InputMethodServiceTest
Change-Id: I99e7c413fe1a93f8d8cff897b5c5f0947690d2c0
This is a follow up CL to a recent CL [1], which aimed to move several
APIs only for InputMethodService from InputMethodManager to
InputMethodService.
This CL removes InputMethodService#hideSoftInputFromInputMethod(),
which is exactly the same as InputMethodService#requestHideSelf() that
is already available as a public API for IME developers.
This CL also virtually renames
InputMethodService#showSoftInputFromInputMethod() to
InputMethodService#requestShowSelf(), which has existed as a
private method but not been exposed to IME developers yet.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
Bug: 70282603
Test: atest CtsInputMethodTestCases
Change-Id: If6a786c5774805d041ea9672ef2721e4a38df7fc
This is a safe refactoring that should have no behavior change in
terms of semantics and performance characteristics.
Test: make -j checkbuild
Change-Id: I30b40c483e490ff42c1c707233ca5cc7b67da28f
This is a follow up CL to a recent CL [1], which deprecated several
APIs InputMethodManager class but forgot to update some of existing
call sites in InputMethodService to use new method names.
This CL only addresses deprecated API usage warnings. There should be
no behavior change.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
Bug: 70282603
Test: atest CtsInputMethodTestCases
Change-Id: I709ca997523ac9a9cd2d236f3158bbb18cf2edc3
With this CL, DecorView#mNavigationGuard that handles navigation bar
only for IME windows [1] is finally gone and replaced with the
standard mechanism to handle navigation bar layout padding /
background color.
This CL addresses multiple anomalies regarding how the following APIs
work for IME windows.
* Window#setNavigationBarColor()
* Previous behavior:
- Only works for Color#TRANSPARENT [2].
- Ignores FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS.
* New behavior:
- Works as documented.
- Requires FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS to work.
* SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION flag
* Previous behavior:
- The system automatically sets
SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION to the IME windows [3].
- Does not work as documented. Content area is not extended to the
navigation bar area.
- Manually unsetting SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION can cause
unexpected layout, because the system expects that this flag is
always set to the IME window.
- Had a special logic for FLAG_LAYOUT_IN_OVERSCAN [4].
* New behavior:
- Works as documented.
- Can set/unset as necessary.
From the viewpoint of IME developers, this CL enables IME windows to
* correctly extend the input view to the navigation bar region by
using SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION as documented, instead of
relying on a special hack with FLAG_LAYOUT_IN_OVERSCAN hack.
* use Window#setNavigationBarColor() to easily change the navigation
bar background color, like other non-floating windows.
Note that SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR is not yet supported for
IME windows, which will be implemented in a subsequent CL.
[1]: I6a93f30aec83f1cecfb854073046cbc87ab4aa66
ae3349e1c3
[2]: Iea77915ecc55eedaf19899e72c44f704ba9d852c
0a9d1ea015
[3]: I460912ee7c117480c57b947ed31eca330819f32c
c68d577f29
[4]: Ic38f204a892bf34e8dae65990d5aa8c95af555d8
9b32a35aa7
[5]: I4b10a19641bd3ce6c43e7629404b6f202d4186e8
Fix: 25706186
Bug: 69002467
Test: ThemedNavBarKeyboard sample [5] works for the following cases
* Extended Dark Navigation Bar
* Separate Dark Navigation Bar
* Floating Mode (if the target app uses dark navigation bar)
Change-Id: I664630099b6eb3fe31675444ba94944cb0eb98b0
InputMethodManager is public InputMethod API for apps. The methods
that take Window-token as parameter are restricted to system
and/or IME developers. Such methods should really live
in InputMethodService.
This CL deprecates such methods in IMM and moves them to IMS.
This is the first step towards simplifying IME APIs.
Bug: 70282603
Test: atest InputMethodManagerTest
Change-Id: I3163f3cbe557c85103ca287bee0874a3b4194032
Now before we fire an a11y event we check if this event has an
observer. As a bonus we don't push the state to clients if the
dynamic service config did not change.
Test: cts-tradefed run cts-dev -m CtsAccessibilityServiceTestCases
bug:69427760
Change-Id: Ie208e13b8557bb7a120198a43efcb79c2752f5db
InputConnectionWrapper has several synchronous methods which have a
timeout. If the application's UI thread hangs, all these synchronous
methods are blocked and IME stays on-screen.
This CL aims to improve the responsiveness of IMEs by rejecting
any blocking calls of InputConnection APIs once
IInputMethod#unbindInput() is issued by InputMethodManagerService
(IMMS).
Currently #unbindInput() is issued only from
IMMS#unbindCurrentClientLocked(), which basically means that the
previous application is losing the IME focus.
Underlying #onUnbindInput() signal is still immediately delivered
to the IME process, but it's just waiting to be consumed on the UI thread.
Hence in theory we can change the behavior of InputConnection seen
from the IME once the signal is delivered to the IME process.
This CL does not interrupt already blocked API calls, which is one of
future work for this scenario. This CL relies on:
A. IInputMethod is marked as oneway
B. IMMS guarantees that IInputMethod#bindInput() and
IInputMethod#unbindInput() are always paired without nesting,
and IInputMethod#startInput() is called 0 or more times only
during that pair.
In this case, the system guarantees that IInputMethod methods
will be called back in the IME process in the same order, and only
one IPC thread is handling those IPCs at the same time. See the
JavaDoc of IBinder#FLAG_ONEWAY for details.
Bug: 36897707
Test: Manual: using the apk in the linked bug:
1. Make sure that a valid InputConnection is established between
the test app and a test IME.
2. Let the test app start blocking the UI thread.
3. Let the test IME call InputConnection#getTextBeforeCursor()
three times.
4. Tap the Home button on the NavBar.
5. Make sure that the test app is immediately dismissed.
6. Make sure that InputConnection#getTextBeforeCursor() starts
returning immediately, once after the initial call was timed-
out after 2 sec (InputConnectionWrapper#MAX_WAIT_TIME_MILLIS)
Change-Id: I0f816c6ca4c5c0664962432b913f074605fedd27
This is a preparation to work on Bug 36897707.
For instance, the reason why most of IME-related callbacks in
InputMethodService get called on the main thread is because
IInputMethodWrapper keeps forwarding incoming IPCs into the
main looper of the IME process as follows:
InputMethodManagerService (IMMS)
------
-> one-way binder IPCs over IInputMethod
------
-> IInputMethodWrapper (on the binder thread(s))
-> Handler (to dispatch tasks to main thread)
-> InputMethodImpl.* (on the main thread)
-> InputMethodService.* (on the main thread)
By adding explicit annotations such as @BinderThread and @MainThread
in relevant methods, this CL makes that kind of investigation much
easier than before.
Bug: 36897707
Test: compile
Change-Id: I8f9afe9a1986a9fa41fb66fdc64e8f0f67e45c2e
This CL is a safe and no-op code clean-up, including dead code removal.
There should be no behavior change.
Test: continuous tests
Bug: 36897707
Change-Id: I4a1ad9cb764c7ba82b32e325c4a4b1c8e7296bbf
Consider this VirtualDisplay (VD) scenario:
HostActivity creates a VD which holds SettingsActivity. When EditText
on SettingsActivity is tapped, it gains focus.
On eventual taps, it loses focus i.e. the Window in VD loses focus and
the host activity in primary display gets the focus instead. This
happens because WM's TaskTapPointerEventListener.onPointerEvent()
is called on the default display only.
Root cause:
1. Tap detector isn't registered for non-default display.
2. Tap detector has no info on which displayId touch was received.
3. InputFlinger doesn't deliver InputMonitor events for
non-default displays (fixed in a separate CL)
Fixing above results in onPointerEvent(MotionEvent) to deliver the
Touch events successfully to VD. We restrict these changes to physical
multi-displays and VR VirtualDisplays (which uses virtual touch device).
[VrManagerService calls WMInternal.setVr2dDisplayId(int)]
In future, displayId should be part of InputEvent. Bug: 64258305
Bug: 62033391
Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests
Change-Id: I3626f4de5aa9bcf905da9abd39f3ab1baefc4c48
Percentage-base sizes involving screen height are incorrect for watch
devices with non 1:1 display metrics. These are round screens with an
inactive bottom portion. To maintain the correct proportions the
bottom inset must be added to the height.
BUG: 36728475
Change-Id: Ibe351d1db7964b4b89ce9a588c171cd8407e2a50
This will now be controlled by individual accessibility services.
We'll provide the password information to them, and they can
present or hide the information as it makes sense for their users.
Password information was anyway provided when a headset was
connected.
Bug: 28139568
Test: Manually verified that TalkBack now speaks passwords on the
lock screen and in text views. Since I'm removing functionality
that didn't have tests, it's tricky to have specific tests.
Change-Id: Ic3c724ccce5762ee9dcd9e7dcbd4eae6734dd05e
This is another follow up CL to my previous CL [1], which had a bug
that InputMethodService#doStartInput() is now always called back twice.
There was a careless mistake when rebasing the CL [1] onto the previous
CL [2], which ended up with dispatching startInput() twice in
IInputMethodWrapper.
In short, InputMethod#dispatchStartInputWithToken() is the new way to
dispatch startInput()/restartInput(). We do not need to call both of
them.
[1]: I9921b381e02106dbffff5e0b3d13f0a1245ce807
6db3bfe33d
[2]: I476d0cf8cbb0a0134941854f9337d9ad15e66a71
f7526b5896
Test: Set true to InputMethodService#DEBUG and make sure startInput()
and restartInput() are called in the following scenario.
1. Complete the setup wizard.
2. adb shell am start -a android.app.action.SET_NEW_PASSWORD
3. Proceed to "Choose your password" page
4. Make sure startInput() gets called only once.
5. Type "aaaa" then hit "CONTINUE" button.
6. Make sure restartInput() gets called only once.
Bug: 35079353
Fixes: 35442939
Change-Id: Ifde16c3fad5b787d4c9a11bd886943dfe96f9eb9
This is part of work to introduce historical debugging infrastructure
for Android IME.
In this CL, we will focus on the following two event flows.
A1. IMMS#attachNewInputLocked() queues MSG_(RE)START_INPUT to deliver
new InputConnection/EditorInfo to the current IME
A2. The IME triggers IMS#onStartInput()/IMS#onRestartInput() and
updates the following fields:
- InputMethodService#mStartedInputConnection
- InputMethodService#mInputEditorInfo
B1. IME is expected to call back IMM#setImeWindowStatus() to notify
its window visibility change to IMMS.
B2. IMMS updates the following field if the caller is still the
current IME.
- InputMethodManagerService#mImeWindowVis
What this CL aims to do is to enable IMMS to access A1 state when it
was in B2 state, by considering that for given a B1 the last A2
happened before B1 is the cause of B1 and B2.
To do this, IMMS issues a binder token in A1 and each IME keeps it
so that it can be passed in B1. By using this Binder token as a key,
IMMS can keep tracking state snapshot taken from each A1. Note that
those state snapshots keep alive until the Binder token's proxy in the
IME process loses strong reference from its GC root.
Test: Make sure `adb shell dumpsys input_method | grep mImeWindowVis`
matches to the IME window visibility.
Test: Make sure the current IME is not receiving any
InvalidParameterException from IMMS.
Bug: 35079353
Change-Id: I9921b381e02106dbffff5e0b3d13f0a1245ce807
This is the 2nd attempt to merge restartInput into startInput in
internal IPC after fixing the mistake in new parameter order in
the previous CL [1].
As a preparation to start tracking all the event flows that
cause InputMethodManagerService#setImeWindowStatus(), this CL
merges an internal IPC method IInputMethod#restartInput() into
IInputMethod#startInput() in favor of simplicity.
This is a refactoring CL that should have no behavior change.
[1]: Ifda6f74ac1b1370d9e9a9fe60354b692121fdcb9
1a5838e966
Test: Set true to InputMethodService#DEBUG and make sure startInput()
and restartInput() are called in the following scenario.
1. Complete the setup wizard.
2. adb shell am start -a android.app.action.SET_NEW_PASSWORD
3. Proceed to "Choose your password" page
4. Make sure startInput() gets called.
5. Type "aaaa" then hit "CONTINUE" button.
6. Make sure restartInput() gets called.
Bug: 35079353
Change-Id: I476d0cf8cbb0a0134941854f9337d9ad15e66a71
This reverts commit 1a5838e966 [1].
Reason of revert:
There was a mistake in the parameter order of MSG_START_INPUT.
[1]: Ifda6f74ac1b1370d9e9a9fe60354b692121fdcb9
Test: none. This is a revert.
Bug: 35079353
Change-Id: Ic1487768932febe0f1f1b6e71929464e91f357e0
As a preparation to start tracking all the event flows that
cause InputMethodManagerService#setImeWindowStatus(), this CL
merges an internal IPC method IInputMethod#restartInput() into
IInputMethod#startInput() in favor of simplicity.
Test: Done some quick manual testing to make sure that IME is
still working
Bug: 35079353
Change-Id: Ifda6f74ac1b1370d9e9a9fe60354b692121fdcb9
As explained in the commit message of my previous CL [1], we have
had a design issue in how to notify the full-screen mode change
from the IME to InputMethodManager running in the target application.
Histrically we have done this by using hooking the following IPC
from the IME to the target application.
InputConnection#reportFullscreenMode()
However, since we also want InputConnection to be deactivated in some
situations such as the when the target application is no longer
focused. In other words, InputConnection is not a reliable way to
notify something.
As a result, we have suffered from many stale state issues.
Bug 21455064 and Bug 28157836 are such examples. In Android N, we
introduced yet another hack to work around those issues, but it is
really time to fix the protocol design instead.
The new strategy is to rely on internal IPCs provided by
InputMethodManager to deliver such critical notifications from one
process to the other. This is actually more natural because our goal
is to make sure that InputMethodManager#isFullscreenMode() always
returns the latest value as long as the caller is the focused
application.
For backword compatibility, applications that are monitoring
this callback should continue working, as InputMethodManager emulates
the previous behavior. However, as updated in JavaDoc, IMEs are no
longer allowed to invoke InputConnection#reportFullscreenMode(),
which should be OK because even on previous releases IMEs should rely on
InputMethodService#updateFullscreenMode() instead.
[1]: Iba184245a01a3b340f006bc4e415d304de3c2696
1544def0fa
Fixes: 28406127
Test: Make sure Bug 21455064 is still fixed.
1. Input some words in extract mode.
2. Select a word.
3. Perform copy.
4. Select a word.
5. Rotate the device.
6. Try to select a word.
7. Make sure he word is selected and action mode starts.
Test: Make sure Bug 28157836 is still fixed.
1. Rotate device to landscape mode.
2. Tap on EditText and start full screen extracted mode.
3. Rotate device to portrait mode.
4. Long press to start action mode.
5. Make sure Action mode gets started.
Test: `adb shell dumpsys input_method` to make sure that fullscreen
state is synchronized across the app, IMMS, and the IME.
Change-Id: If23e7c7c265ab3dfb48c2fb6fdb361b17d22c594
This CL hides warning and info log messages from
InputMethodManagerService (IMMS) and InputMethodService (IMS) behind
DEBUG flag like other logs unless the state is certainly unusual.
Of course the definition of "unusual" is still an open question, but
basically that we should not see any suspicious message from IMMS/IMS
just by turning on a new phone, launching some applications, typing
something, and turning off the device. IMMS and IMS should expect all
events that can (easily) occur in that scenario, and no log is
necessary for such things.
Note that warnings suppressed with TODO comments will be tracked
under Bug 34851776 (and Bug 34886274).
Test: adb logcat -s InputMethodManagerService:* InputMethodService:*
to monitor log in the following scenario:
1. Boot the device.
2. Complete the setup wizard.
3. Launch Dialer and type something on it.
4. Launch Contacts app and type something on it.
5. Try some special modes:
- Turn on/off display
- Recents screen
- Split-window mode
- Guest user
- Multi user
- Direct-boot (setup a device password and reboot)
except for logs about actual IPC calls from a background user.
Bug: 34838583
Bug: 34851776
Bug: 34886274
Change-Id: I3fcdeb919bb2f2940da9ff45e17ac00baa1253f4
This makes it clear that on Android L+ devices IME developers basically
no longer need to call InputMethodService#enableHardwareAcceleration(),
because it is deprecated in Android L[1][2]. On L+ devices what IME
developers need to do is to make sure that their IMEs are compatible
with both hardware and software rendering so that the system can choose
the best rendering method.
This is basically a code clean-up that should not change any actual
behavior.
[1]: I906d48cb07af50fa02dae4f4ecdb5e65211fc6ef
5e1565ead6
[2]: I126ea823eb2eeabb29d30999dec9c9411b33b315
e07b595519
Bug: 31202732
Change-Id: I416669b172737e3eb3d77165dcea50289d207514
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
25e0813e6e
Bug: 29450031
Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
This is a follow up CL to my previous CLs [1][2] that introduced
InputConnection#commitContent(InputContentInfo, Bundle) API to enable
IMEs to send a content to the target application.
With this CL, IME developers are able to temporarily expose
InputContentInfo object to the target package without permanently
granting URI permission. Although calling IMS#exposeContent() is
allowed only for the IME that is currently selected, the client is able
to request a temporary read-only access even after the current IME is
switched to any other IME as long as the client keeps InputContentInfo
object.
Here is a sample code snippet about how to use this mechanism.
[IME]
InputContentInfo contentInfo = new InputContentInfo(
contentUri,
new ClipDescription(description, new String[]{mimeType}),
linkUrl);
exposeContent(contentInfo, getCurrentInputEditorInfo());
getCurrentInputConnection().commitContent(inputContentInfo, null);
[App]
try {
contentInfo.requestPermission();
// Load inputContentInfo.getContentUri() here.
} finally {
contentInfo.releasePermission();
}
[1]: Iaadf934a997ffcd6000a516cc3c1873db56e60ad
152944f490
[2]: Ica1ba3154795c1bf44e140dfe639b299f83cd8af
adebb52588
Bug: 29450031
Change-Id: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
