When we use Bundle's copy constructor we perform a shallow copy of the
underlying map, so lazy values are the same across the original and the
clone. So, if we're accessing the same item backed by a lazy value in 2
different threads, each one accessing a different bundle (the original
and the clone), both would have to synchronize on a common lock.
Although Bundle is not thread-safe, we should keep the expectation that
the client only needs to properly synchronize access to one bundle, not
more. To achieve this, we synchronize on the original parcel held by
LazyValue in get(), this removes the need for the above.
Note that after we produce the lazy values and put them in the map, we
don't have a reference to mParcelledData anymore inside the Bundle, the
only objects holding a reference to that parcel are the lazy values.
Also fixed some stuff in LazyValue:
* Fixed condition inside LazyValue that used mObject == null as
signal for "not deserialized" state since mObject can be null, so
switched to mSource != null.
* Made mSource volatile and adjusted operations to always check it
before, ensuring visibility of itself and mObject via happens-before.
This works because after checking mSource, if that's null, mObject is
guaranteed to be visible and valid, if it's not null, we can use it
since we're in the serialized state and this works even if another
thread deserializes in between as long as we hold on to a reference of
mSource in a local because the parcel is still valid.
* Remove the recycling of mValueParcel, otherwise we'd need locking to
ensure whatever was using it was still using a valid object. Decided
to just remove recycling for now since the plan is to remove
mValueParcel entirely when we add comparison and hasFileDescriptor()
methods that operate on a range to Parcel.
Bug: 195622897
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest
android.os.BundleTest android.os.ParcelTest
Test: More tests coming
Change-Id: I501c91f505950338b23e7837e55f89b2f63ff93a
Since the EffectCallback in android::AudioEffect can
keep an instance of the latter alive for a longer time
than Java AudioEffect is alive, the callback need to
ensure that it's not trying to use deallocated objects
and deleted JVM references.
Bug: 178363662
Test: manual using EffectsTest app
Test: atest CtsMediaTestCases:AudioEffectTest
Test: atest CtsMediaTestCases:BassBoostTest
Test: atest CtsMediaTestCases:DynamicsProcessingTest
Test: atest CtsMediaTestCases:EnvReverbTest
Test: atest CtsMediaTestCases:EqualizerTest
Test: atest CtsMediaTestCases:LoudnessEnhancerTest
Test: atest CtsMediaTestCases:PresetReverbTest
Test: atest CtsMediaTestCases:VisualizerTest
Change-Id: I8c36f5af4a1a2b14e81b1344570d2f8746ffa91e
Add repro code to the EffectsTest app. Steps:
1. Start playback on the "Environmental Reverb Test",
memorize the session id.
2. Enter the session id on the "Bass Boost Test" or
the "Visualizer" tab.
3. Press "Hammer on release()" multiple times and check
if the app crashes. Currently this happens for
the Bass Boost effect.
Bug: 178363662
Test: see above
Change-Id: I800bc352fc8bc7073d1523c837008dc6fcfb957a
Bluetooth can no longer call SystemConfig and need to use the manager.
Bug: 190440540
Bug: 199279027
Test: Manual
Tag: #refactor
Change-Id: I065ab407c83cd2edf2244e4170496b0979ac562c
The entire service state should be deep copied, instead of shallow
copied to the other object.
Fix: 174306612
Test: Manual
Merged-In: Ib6ad4ba26653ce5faad1e118a28d8be51435676c
Change-Id: Ib6ad4ba26653ce5faad1e118a28d8be51435676c
(cherry picked from commit 579f130ee3)
For isInbandringing API - it is used in the call journey and would
change the behavior(undeterministic) of the call if not used.
Stop/StartScoUsingVirtualVoiceCall is used in the BluetoothShim layer
specifically for testing and mocking in the Android Apps. Seems
reasonable to keep this as a SystemAPI given that it has no params and
unlikely to be changed.
Bug: 195160939
Tag: #feature
Test: Manual
Merged-In: I02b2e7e5e0be3b462f7c25b655e669e2c7fe47eb
Change-Id: I02b2e7e5e0be3b462f7c25b655e669e2c7fe47eb
[Description]
inputState will override by wrong state
when call onStateChaned directly.
[Test Report]
Test pass
Bug: 196189979
Change-Id: I13377407c9ea9f4f0727edea5d57135c6569cba0
This helps functions like tmpnam() and tmpfile() to "just work", like
their Java equivalents.
Bug: https://issuetracker.google.com/36991167
Bug: http://b/174682340
Test: atest FrameworksCoreTests:android.app.activity.ActivityThreadTest
Change-Id: Ife785f0ca69a34ba2c6b5d1e8e23f8b883d8fc8f
TracFone informed that the short code "611611" is owned by TracFone and this is for the free messages for the TracFone customers.
TracFone webpage for 611611 use cases: https://dsweb.tracfone.com/611611/help/
BUG: 198667013
Test: ShortCodes are tested in the USA by leesung@google.com.
Change-Id: I6addc2c6a25e774cf9ba905b837e15caaed3c9bc
Signed-off-by: Shawn (Yu-Hsiang) Lien <shawnlien@google.com>
Due to lazy bundle, we can now have bundles touching the original parcel
(used to create the bundle in the first place) during serialization.
This can lead to races within the same bundle or across bundles when
the same is copied.
Both these cases happen in notification manager when it's about to post
notification for its listeners. In summary, it notifies all the
listeners in oneway calls and the listeners make a call back to
system_server to retrieve the notification. These calls back can race
and lead to the bug observed in http://b/198355758#comment12.
In order to avoid that we use appendFrom(mSource, mPosition) in
LazyValue.writeToParcel() since that method doesn't change or use the
cursor of mSource. We only ever write to mSource before creating all the
LazyValues, so there can't be any r/w races.
Test: 1. Attach debugger to system server and put log breakpoints in
racy lines in Parcel$LazyValue.writeToParcel
2. atest -d CtsHostsideNetworkTests:com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testDozeModeMetered_enabledButWhitelistedOnNotificationAction
3. Observe no crashes
Test: 1. Attach debugger as in previous "Test:" line
2. Create a notification with a parcelable extra, post it
3. Observe no crashes
Bug: 195622897
Bug: 198355758
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Change-Id: I02f890d22910c69e29e791b55d3655962a6dddfd
BluetoothHandler was not able to tell whether the MESSAGE_ENABLE was
from enable() or enableBle(), which sometimes lead to Bluetooth gets
turned to STATE_ON by an enableBle() call.
Fix this problem by adding a BLE specific argument in the message to
differ the calls.
Bug: 191404687
Test: Manual
Change-Id: Ic9df612ec0e396932df2fb3bf3a5874bd4e7443c
Merged-In: Ic9df612ec0e396932df2fb3bf3a5874bd4e7443c
`filename` must be `null` at this point, as it's recently been set to that value, and hasn't adopted any other value yet.
Refactoring change only. No functional changes intended.
Change-Id: I29a28872efc8c12c0da3c9f7c0a92d6aff465410
- add getSlicingConfig() API in TelephonyManager and ITelephony
- add Parcelable implmentations for RouteSelectionDescriptor,
SlicingConfig, and UrspRule
- remove @hide and @SystemApi for TrafficDescriptor and
NetworkSliceInfo to make them public
Bug: 178075247
Test: .
(1) run "atest TelephonyManagerTest#testGetSlicingConfig" for CTS result
[22/121] android.telephony.cts.TelephonyManagerTest#testGetSlicingConfig: PASSED (956ms)
(2) run "atest RILTest#testGetSlicingConfig" for RILTest result
[17/111] com.android.internal.telephony.RILTest#testGetSlicingConfig: PASSED (1ms)
Change-Id: I0addc2b22c11b13759e890d88f51490993fb72e1
Merged-In: I0addc2b22c11b13759e890d88f51490993fb72e1
Expose requestModemActivityInfo in TelephonyManager using the Executor +
Consumer pattern, and modify clients to use it.
Test: atest TelephonyManagerTest#testRequestModemActivityInfo
Fixes: 170427831
Change-Id: I7e8134c8058017b888c324a9f85d473fc3cdd8f5
Merged-In: I7e8134c8058017b888c324a9f85d473fc3cdd8f5
Update ModemActivityInfo to present a nicer API surface and expose it as
a SystemApi. Also change clients in BatteryStats to match the new
surface.
This is part 1. Part 2 will modify the methods in TelephonyManager to
use a more up-to-standards threading model.
Bug: 170427831
Test: atest ModemActivityInfoTest
Change-Id: I762ed949342861c75d94eafce88335e7bd8c9139
Merged-In: I762ed949342861c75d94eafce88335e7bd8c9139
