Also sets an explicit type for GeolocationPermissions.getOrigins.
This is a partial fix for bug http://b/issue?id=2271636
This has already been submitted to eclair-mr2.
Change-Id: I0c77eca94eb56d16c2a9a29a72eb221e4a7a52a6
This change allows applications to nest children RemoteViews
inside an existing set of RemoteViews. These nested views
are inflated and treated as addView() calls.
This change also allows ViewFlipper through RemoteViews, and
adds logic surpress flipping when the parent window is
detached or behind the lockscreen. Also fixes ViewAnimator
to observe the measureAllChildren flag when set.
Fixes http://b/2239905
Also reworks this intent protocol a little bit to be much more efficient, only
requiring one broadcast per package.
Change-Id: I580de4843ebd3c7f2e6df7295a2f80d2937cef7c
You can no longer receive CONFIGURATION_CHANGED in a manifest, which is really really
bad (launching apps every time the screen is rotated!). A new LOCALE_CHANGED broadcast
is sent that you can receive in a manifest.
Change-Id: I80022375f0716db2e672382a29db3cea1af74702
the apis to SDK.
Remove @hide in GeolocationPermissions and WebStorage
to expose them to the SDK users.
Remove @hide for freeMemory() in WebView.
Remove @hide comment in CallbackProxy and
GoogleLocationSettingManager as they are not public class.
Merge commit '91bb62f0dc002065cb1932a96fecf15c1b92b6e9' into eclair
* commit '91bb62f0dc002065cb1932a96fecf15c1b92b6e9':
New API 4 with new CDMA constants.
This is the main entry point to the Bluetooth APIs, and returns the default
local Bluetooth adapter.
It replaces context.getSystemService(Context.BLUETOOTH_SERVICE). This was
never in a public SDK release.
DrNo: eastham
Bug: 2158765
Joke: Why can't you play cards in the jungle? Because there's too many cheetas!
Change-Id: Ieed8be009ee5aba621cb69090ee8c8a9c19c840d
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
- remove updateEntity and insertEntity, since they are not
used
- add the RawContacts.Entity class, which is used in lieu of the
android.content.Entity
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
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
