NeighboringCellInfo works in GSM and UMTS network.
In GSM network, the locaiton value is the combination of LAC and CID.
In UMTS network, the locaiton value is PSC code.
NeighboringCellInfo should access and store those two values seperately.
It involves the change of Public API.
1. Add new API getRadioType(), getLac(), and getPsc() to get location info in GSM and UMTS.
2. Deprecate setCid() and NeighboringCellInfo(int cid) because cid is set by interpreting network type.
The TelephonyRegistry service crashed badly in the generic build, because
there is no system property to tell if the phone is GSM or CDMA. Adding a
simple null check solves the issue and allows the system to boot properly.
Merge commit 'c1828d5a492a14a9b15e9106684079049317313e' into eclair
* commit 'c1828d5a492a14a9b15e9106684079049317313e':
implement browser history for tabbed search results...
* changes:
implement browser history for tabbed search results... this adds a parameter to the URL hash on all search queries. the main motive is to allow searches from the blog to automatically open the blog tab.
This prevents QSB from obscuring the results when they are handled
by the current application.
Bug: 2141208
Change-Id: I6f848aa2003c75b97effe1d3d2af5316ad4fbf92
- The lock screen now fades in and out.
- Fixed a bug where we would accidentally freeze the screen when switching
to an activity with a different orientation than the current (but
the screen itself is in the current orientation). This would mess up
the animations on the car dock.
- New API to force a particular animation for an activity transition
(untested).
- New wallpaper animations.
- Resources now uses the next API version when in a development build,
to help applications being developed against such builds.
Change-Id: I2d9998f8400967ff09a04d693dc4ce55f0dbef5b
When the AudioTrack callback notification size is relatively high (Which is the case on Sholes and over A2DP), it is likely that the end of tone is reached during the first callback. In this case, the AudioTrack is stopped before exiting the callback which causes 2 problems:
- 1: If the AudioFlinger thread is scheduled before we exit the ToneGenerator callback, the track can be stopped and reset before the data is actually marked as present in the buffer by the AudioTrack callback => no audio will be processed by AudioFlinger.
- 2: In this case, the data write index in the AudioTrack buffer is incremented after the track was reset by the AudioFlinger which leaves unplayed data in the buffer. This data will be played the next time the AudioTrack is started if not flushed in between.
The fix consists in adding an intermediate state to ToneGenerator state machine so that we exit the callback function when the stop condition is reached and stop the AudioTrack the next time we execute the callback.
* changes:
Fix bug 2129190 The context used by the status bar (i.e., the system context) was not properly initialized to have the right ApplicationInfo inside its PackageInfo. This eventually caused it to believe that it was running at 160dpi.
The context used by the status bar (i.e., the system context) was
not properly initialized to have the right ApplicationInfo inside
its PackageInfo. This eventually caused it to believe that it
was running at 160dpi.
Kudos to Dianne for figuring this out.
this adds a parameter to the URL hash on all search queries.
the main motive is to allow searches from the blog to automatically open the blog tab.
Change-Id: Ib81896948e63e8173d521713496bb98065683ce7
Merge commit '20972da079adb6e53fe5f8758aa473d9d46a1b54' into eclair
* commit '20972da079adb6e53fe5f8758aa473d9d46a1b54':
New localization document and tutorial
* We now check for in-progress backups when asked to perform one, and don't
bother firing off another one concurrently (nor do we adjust the scheduling;
after all, someone asked to do a backup "now" and we're doing one, so we are
in line with expectations). We also defer backup passes while a restore is
in flight, and abort attempts to perform a restore during a backup pass.
* When a backup attempt fails, we now ask the transport how far in the future we
should put our retry. Previously we were simply not bothering to consult with
the transport, so we would wind up retrying backup while network connectivity
was known to be down, etc.
Change-Id: Ic7758010b74e06e90c50d46b7b0dd01b17af7c90
Instead add ACTION_REQUEST_DISCOVERABLE for the system to show a dialog to
adjust discoverable mode.
Also remove createBond(), removeBond() and cancelBondProcess(). The Settings
App already handles these automatically when connections require bonding.
Change-Id: I216154cd1b6de410de64ba91b07d7263ac03e8df
* changes:
Suppress the testPing as we moved the release test target to the userdebug. This test rely on a mock_media_player.so which build under the eng build
