Hide createRfcommSocket(int channel)
Add createRfcommSocketWithServiceRecord(UUID uuid)
Rename listenUsingRfcomm(String,UUID) -> listenUsingRfcommWithServiceRecord(..)
Now we have a complete API for developers to make peer-peer RFCOMM connections
with hard-coding the limited (30) RFCOMM channels, instead using SDP lookup
of an UUID.
This commit addresses two serious bugs:
- Do not throw IOException on accepting an incoming RFCOMM connection with
BluetoothSocket. This was a regression from commit 24bb9b8af4ff6915
- Workaround failure of bluez to update SDP cache when channel changes by
trying to use the same RFCOMM channel on the server every time, instead
of picking server channels randomly. This is a pretty ugly workaround,
and we are still trying to fix the caching issue - but with this
workaround we are at least shippable and apps will work at least until
they start colliding on the 30 RFCOMM channels.
DrNo: eastham
Bug: 2158900
Joke: What did the digital watch say to his mom? "Look mom no hands."
Change-Id: Ia4879943b83afac06b6f1a3f2391cf1628afce7d
Don't hold a lock when the activity thread is telling the activity manager
to release a provider.
This requires that the activity manager now keep a reference count on the
providers, because without the lock it is possible for activity thread to
call in to request the provider again before it has finished telling
about the release.
Change-Id: I5f912903891f4edae85e28819d4e6f14b8f2e688
AutoCompleteTextView.onKeyPreIme() used
getKeyDispatcherState().startTracking(event, this) to start tracking
the back button, but didn't update the state of the event
before checking event.isTracking().
Fixes http://b/issue?id=2167168
"AutoCompleteTextView back button handling is broken"
Change-Id: I2c5f1e761872b9e02d85ff6f958fabd558d041a0
- remove updateEntity and insertEntity, since they are not
used
- add the RawContacts.Entity class, which is used in lieu of the
android.content.Entity
* changes:
Make sdk version and code names static finals in PackageParser. Remove api to set these values. Remove an unused method in AppSecurityPermissions
Previously the creation was delayed until addHandler(), which
had been required to be called.
However, after VCardComoser's support toward PBAP stuffs,
the guarantee was not true any more.
So by creating the instance in constructor, we refrain NPE during
finalize() when PBAP uses VCardComposer.
Hide listenUsingRfcommOn(int channel)
Add listenUsingRfcomm(String name, ParcelUuid uuid)
The new API automatically finds a free RFCOMM channel and registers an SDP
record with the given uuid and name. The SDP record is automatically
removed when the socket is closed, or if the application dies.
Apps are prevented from registering SDP records with the uuid of system
Bluetooth profiles, such as A2DP, HFP and OPP.
Apps are prevented from removing SDP records that they did not create. This is
tracked by pid.
TODO: Provide an API for the connecting app to look up an SDP record.
Bug: 2158900
DrNo: eastham
Joke: "What did the dog say to the tree? bark."
Change-Id: Ia92f51c34615a7270a403255ad2b8faa98c4a3f5
Tell the broadcast receiver whether it is getting an initial sticky value,
so it will be quiet about attempts to do ordered broadcast stuff.
Note that the original bug being reported was not actually a crash, just
an error log. So all we are doing here is making the log quieter.
Change-Id: Iaf1b718d82093ec1197142410a64feff47eb3859
This is in accordance to the documentation. This bug was approved by hackbod.
The change is safe and is a single line of code.
Change-Id: I9b771df3ae2aa4f496d15e6c43b677f3245539ac
Change https://android-git.corp.google.com/g/27729 started reinflating
the entire search bar every time the search source was changed, to get
around problems with bad state in AutoCompleteTextView
(http://b/issue?id=2132686). This had some side-effects if the
search dialog was already visible, as it is when selecting a
source in "More results" or when presing the search key to go to
QSB from in-app search.
This change changes the reinflation to only happen if the dialog is
not already showing.
Fixes:
http://b/issue?id=2166640
"After selecting More results from suggestions, the search box is no longer visible."
http://b/issue?id=2166675
"Calling QSB with the hardware key does not place focus in the search tab."
http://b/issue?id=2166712
"back key has unexpected behaviour in QSB after selecting "More results" from suggestions."
Change-Id: I8d48149c3e9ad97ec11c49ec7efb356f27dfe4f6
This is the frameworks/base part of the fix for Bug 2158434: add a new
callback to the OnDialTriggerListener interface, so the RotarySelector can
tell the app about state changes between NOTHING_GRABBED and
LEFT_HANDLE_GRABBED and RIGHT_HANDLE_GRABBED.
BUG=2158434
DRNO=timsullivan
TESTED=regular incoming calls, call waiting calls, answering a call,
rejecting a call. Also verified I didn't affect the
lock screen at all.
Since a fullscreen IME covers the entire search dialog, there was
no discoverable way to get back to the search dialog.
Now, on BACK presses when the IME is fullscreen (e.g. in landscape
mode without hard keyboard), we dismiss only the IME.
A second BACK press will dismiss the search dialog.
Fixes http://b/issue?id=2159132
Change-Id: I8e5736d83d7c35936a718929017ea04c6214700b
API council says:
"In reviewing the new triggerSearch API, we are concerned that
applications could use the option to perform a global search to spam
the user with frequent searches. We would like the global search
option to be removed for now (not just hidden, but removed from the
internal IPC API so that nobody can find this and abuse it). The rest
of the API should be fine as long as it is restricted to local
searches."
Fixes http://b/editIssue?id=2158785
Change-Id: Ie69a9c0ab6373cc4427aab50606885bdede40585
(when booted while docked)
This isn't really a fix, but we now have the activity report the configuration
it actually launched in, so the activity manager will later adjust it if
needed. Should help us recover from hitting the race in this particular case.
Change-Id: I3bb83a48c2d692b4cb1822d8ae7d924cfa9187b2
