SurfaceControl.
In a recent CL we introduced a call to Surface#createFrom, in order to
recreate the Surface object from the underlying SurfaceControl, as a
workaround to emulate when it was parcelled over binder in the past.
However this is causing BufferQueue abandoned errors when stopping and
resuming some applications. To understand them, we need to revisit the
SurfaceView destruction process when handling onStop.
First mWindowStopped will be set to true (SurfaceView#windowStopped),
and we should then enter updateSurface. Our requested visibility will
now be false and so we emit the Surface destroyed callbacks. Notice in
the finally block in mUpdateSurface, we will release mSurface, but we
will NOT null mSurfaceControl. Inline documentation explains why.
In the case that the activity is not actually being destroyed, it's
possible that we may not get a dispatchDetachedFromWindow. This means
that we will not null mSurfaceControl. Now if the activity is
un-stopped and we re-enter updateSurface we encounter a problem
state. "creating" will be set to false since mSurfaceControl != null,
however mSurfaceControl will not point to a valid surface.
Prior to the introduction of the #createFrom call, this unwanted state
didn't cause any problems. Because mSurface was released back in the
finally block as we were stopping we now fall out of the
mSurface.isValid() block in updateSurface. As we reach the finally
block again, we would now set mSurfaceControl=null since the app was
no longer stopped. Later when we reach updateSurface again (which
tends to happen quite often) it will now be null and we will correctly
set creating=true, create a valid SurfaceControl, and move along
happily. However following, the introduction of this
Surface#createFrom call we will now reinitialize the Surface from an
invalid underlying SurfaceControl. This means we will enter the
mSurface.isValid block, but will proceed to emit an invalid Surface to
the client in the callbacks.
We avoid this state by making creating=true even if
SurfaceControl=non-null when the calculated visibility changes from
invisible to visible.
Bug: 63251745
Test: Manual of app from bug and apps from previous related bugs. go/wm-smoke. Additional manual testing of many SV apps.
Change-Id: Icc32a34cac239d65267da705cc23feb23e1ceb67
[Cause of Defect]
In the ContentObserver callback procedure, the binder thread
has no sync mechanism with handler thread.
The ContentObserver#onChange method can get called after
ContentResolver#unregisterContentObserver called in the
very low probability.
Bug: https://issuetracker.google.com/issues/63154326
Test: manual - check https://github.com/nanjingdaqi/ContentObserverDemo
Change-Id: I0e3831eba7a9cc1a5bf0d30abe5dd0ec8259b0d4
Signed-off-by: daqi <daqi@xiaomi.com>
This patch allows to use TYPE_NONE for the legacy network type variable
of NetworkInfo. This usage is "safe" with respect to legacy APIs using
network types as most of them already returns null or do nothing for
TYPE_NONE.
Of the existing APIs in ConnectivityManager that accept a network type
argument, those which were already returning null or doing nothing for
TYPE_NONE are:
getNetworkInfo(int)
getNetworkForType(int)
stopUsingNetworkFeature(int, String)
networkCapabilitiesForType(int)
requestRouteToHostAddress(int, InetAddress)
reportInetCondition(int, int)
isNetworkSupported(int)
getLinkProperties(int)
Only setProvisioningNotificationVisible needs an additional guard
against TYPE_NONE.
Bug: 30088447
Bug: 62844794
Test: runtest frameworks-net
Change-Id: I112596fcd03d3c2cd42a2a84d265adb38e3944bb
This patch allows to use TYPE_NONE for the legacy network type variable
of NetworkInfo. This usage is "safe" with respect to legacy APIs using
network types as most of them already returns null or do nothing for
TYPE_NONE.
Of the existing APIs in ConnectivityManager that accept a network type
argument, those which were already returning null or doing nothing for
TYPE_NONE are:
getNetworkInfo(int)
getNetworkForType(int)
stopUsingNetworkFeature(int, String)
networkCapabilitiesForType(int)
requestRouteToHostAddress(int, InetAddress)
reportInetCondition(int, int)
isNetworkSupported(int)
getLinkProperties(int)
Only setProvisioningNotificationVisible needs an additional guard
against TYPE_NONE.
Bug: 30088447
Bug: 62844794
Test: runtest frameworks-net
Change-Id: I4455f2726d06406047086368628c1f253d854d8d
Override the dump method so RuleManagerService can dump its state
into logs. Crude argument support has been added for dumping
specific fields in an easy to process way (for test scripts to use).
Tested with:
make -j30 FrameworksServicesTests
adb install -r -g \
"out/target/product/angler/data/app/FrameworksServicesTests/FrameworksServicesTests.apk"
adb shell am instrument -e package com.android.server.timezone -w \
com.android.frameworks.servicestests \
"com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner"
Test: See above.
Test: Manual; adb shell dumpsys timezone [-format_state piscotz]
Bug: 31008728
Change-Id: I0ad83aa245232ed0b983ceacd8accfb876824d6f
As per NCI2.0 LF_T3T_PMM is a part of LF_T3T_IDENTIFIER.
Since it is required for each LF_T3T_IDENTIFIER entry,
It can be taken from application.
Test: Compiles.
Change-Id: Icc168592c292d869a4c331dd28fe43b4d75c9a41
* Add related constants to BluetoothHeadset
Bug: 35874078
Test: make, test with supporting headsets
Change-Id: I9f49ea28efdf6de0e751a377d879fe13a47655d5
* Add related constants to BluetoothHeadset
Bug: 35874078
Test: make, test with supporting headsets
Change-Id: Ied089a065bf9caa0d03f681950fefa2ea990bb3e
The attributes for View, paddingHorizontal and paddingVertical,
were added in the O release and are documented in R.attr. But they
should also be referenced in View itself, alongside the other
padding parameters.
Similarly, the new layout_MarginHorizontal and
layout_marginVertical should be referenced in
ViewGroup.MarginLayoutParams.
Bug: 63128350 Add docs about new padding/margin params
Test: built docs, checked the result
Change-Id: I3021df5ea83c469811b4a6ec6ecd3ab2966ec384
* Per HFP 1.7.1 spec page 102 of 144
EXTRA_HF_INDICATORS_IND_ID should be int
EXTRA_HF_INDICATORS_IND_VALUE should be int
Bug: 35874078
Test: make, PTS test, unit tests
runtest -c com.android.bluetooth.btservice.RemoteDevicesTest bluetooth
Change-Id: Idd316a82bab164b6ea1701bb261b1cc3dee196f1
