Don't getApplicationContext if we already have an application.
Test: launch a monodroid app
Change-Id: I0c1558463053de3db0f1cd4693088e7c639ce5fa
Fixes: 63666480
This seems to be causing users who elect not to wipe their eUICC on a
factory reset to end up on the eSIM slot after the reset instead of
the pSIM slot.
Bug: 63693573
Test: TreeHugger + factory reset local test
Change-Id: I414a16cde11e76ccc390e7a63a6803f5b402fe78
Add note for VPN developers that VPN apps started in the background must transition to the foreground in Android O to avoid the system stopping them.
Staged at: go/dac-stage/reference/android/net/VpnService.html
Test: make ds-docs
Bug: 38023983
Change-Id: I33c7ca1717c332ffab495eb51c4c6b9c5c304cef
Previously, TextInputTimePickerView used the default numeric IME, which
could result in cases where the digits displayed in the text fields were
native, but the IME showed ASCII digits resulting in a mix.
Now we use setImeHintLocales to hint that we need a localized IME.
Change-Id: Ic4041dcc65a31bd00741c6d96d8cbc5dac9d77c8
Fixes: 63650251
Test: Manual (tested under en-US and ar-BH locales)
Previously, CameraManager handled a disabled camera service
implicitly, the same as it handles a temporarily-crashed camera
service.
However, the error reporting for the those cases isn't really the
same, so switch to being explicit - check for the disabled camera
service system property, and if it's set, short-circuit calls.
Test: Camera CTS continues to pass, Watch device with no camera
service also now passes camera CTS.
Bug: 62269118
Change-Id: I65a97f8c1b0f101999b2c04d4f1096b7f3aee858
Currently, netd is the only source of tethering statistics.
In order to support multiple sources, define a new
ITetheringStatsProvider interface that can be registered with
NetworkManagmentService. Convert the existing code into the
first ITetheringStatsProvider.
Bug: 29337859
Bug: 32163131
Test: builds, boots
Test: tethering stats continue to be collected
Change-Id: Ie1b5a5e47ae4bf5af922365b09fa241e834236e4
When an application doesn't support tall aspect ratio of the
screen where it's displayed, it should be positioned on the
opposite side from navigation bar. It's supposed to create
an effect of extended black nav bar.
Bug: 62893418
Test: go/wm-smoke
Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarBottom
Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarLeft
Test: ActivityRecordTests#testPositionLimitedAspectRatioNavBarRight
Change-Id: I2cd3d236ee8d0cc263fee4c0a436d78c755eb9b7
Factory reset of eSIM failed due to the euiccWipeFinishReceiver cannot
be registered by the context directly. This CL changes the context to
application context to solve this problem.
Bug: 63610700
Test: E2E
Change-Id: I7e4c8b75b5b5b4203efd7302677ffa5cf00198b5
This changelist identifies aspect ratios set via meta-data tags on
the activity or application and applies them to the proper scope.
Values specified via styled attribute take precedence, and values
specified by the activity take priority over values in at the
application level.
Fixes: 63386222
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsAppTestCases android.app.cts.AspectRatioTests
Test: go/wm-smoke
Change-Id: I0d8d6b2778e7fc12bb9feb85c651e5ec22927f5f
* Allow Java based programs to create an opportunistic GATT client
* Such client does not hold a GATT connection. It automatically
disconnects when no other GATT connections are active for the
remote device.
Bug: 63347806
Test: make, run battery service
Change-Id: Ib9333817d7f17a1fa3ddacfa51c680890bac19ec
Merged-In: Ib9333817d7f17a1fa3ddacfa51c680890bac19ec
(cherry picked from commit 13f52c8118)
This CL reverts the implementation of eSIM factory reset in
MasterClearReceiver and uses RecoverySystem#rebootWipeUserData to erase
eSIM data. Besides this, when the eSIM data isn't erased, we should call
EuiccManager#retainSubscriptionsForFactoryReset to let the fastboot know
that.
Bug: 62957212
Test: TreeHugger
Merged-In: I08ab9d53ec4fc73a65e8e7d0c39ac95b2d44d012
Change-Id: I08ab9d53ec4fc73a65e8e7d0c39ac95b2d44d012
Rotation is a hidden member inside configuration that should not
influence configuration related logic. This CL ensures that we do
not consider changes to the rotation as grounds for relaunching an
activity.
Change-Id: I9e6d4a1a75fd3ee3beb63f307433e9c3fcfd6dd4
Fixes: 63533208
Test: go/wm-smoke
Test:cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerConfigChangeTests
Fixes: 63383044
Test: Ensure all fields of CompanionDeviceManager.CallbackProxy are
null-checked in onSuccess and onFailure
Change-Id: If95a46686f74d184bccfcb2d8c8195add4747a07
In addition to the number they can post. Also decrease
the number of posts per second to 5, but allow finished
progress notifications through.
Fixes: 63173849
Fixes: 63167456
Test: runtests systemui-notification & simultaneously
downloading 5 files.
Change-Id: I0c8ea35b3d9d38b000ea5fe383515e1d5a26bac7
Theme colors should always be the same in sysui and launcher.
We're now sharing a hint HINT_SUPPORTS_DARK_THEME, to make sure
we're never out of sync.
Test: runtest -x tests/Internal/src/android/app/WallpaperColorsTest.java
Fixes: 63140091
Change-Id: Ibd196f540d77269df377804b0f4d4d0d20820067
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
