Status Update
Comments
ub...@gmail.com <ub...@gmail.com> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
sa...@google.com <sa...@google.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
aq...@google.com <aq...@google.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
aq...@google.com <aq...@google.com> #6
aq...@google.com <aq...@google.com> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
ub...@gmail.com <ub...@gmail.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
ub...@gmail.com <ub...@gmail.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
ub...@gmail.com <ub...@gmail.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
ub...@gmail.com <ub...@gmail.com> #11
ub...@gmail.com <ub...@gmail.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
ub...@gmail.com <ub...@gmail.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
ub...@gmail.com <ub...@gmail.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
ub...@gmail.com <ub...@gmail.com> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
aq...@google.com <aq...@google.com> #16
aq...@google.com <aq...@google.com> #17
In conclusion, I was able to reproduce on S (Android 12), but unable to reproduce the issue on T (Android 13) or U (Android 14). I'm attaching the project I used for testing in case you find anything wrong.
Can you use that project to reproduce the issue? If yes, we need to figure out what we are doing differently. Also please kindly include a bugreport (running adb bugreport
shortly after the leak is detected) if you are able to repro.
Please assign back to me once you've replied (if you are not able to, ignore).
ub...@gmail.com <ub...@gmail.com> #18
I've beefed up your example to make it repro the leaks that I attached in #12. I'll attach the updated example. The relevant changes were:
- Run service & receiver in separate process from Activity.
- Customize LeakCanary to support multiple processes.
- Add some additional media-related code to trigger a leak.
Even when not running the service in a separate process there is a leak in the Activity. I'll attach that one, too. May be a similar root cause. I have not investigated this one.
I am attaching the bugreport, too. I took it right after LeakCanary GC'ed and detected a leak. (About 5 seconds after onDestroy().) But it looks easy to reproduce now.
ub...@gmail.com <ub...@gmail.com> #19
(I did the repro on API 33)
ub...@gmail.com <ub...@gmail.com> #20
Also, I don't think non-Googlers are able to reassign an issue, so please take it from here.
aq...@google.com <aq...@google.com> #21
Thanks. Will provide an update in the next few days.
aq...@google.com <aq...@google.com> #22
Correct me if I'm wrong but the only issue we are aware that still exists is in MediaBrowserServiceCompat, right? (not in the platform MediaBrowserService)
I've sent
Once merged, you should just need to update your androidx.media dependency to pick up the fix.
ub...@gmail.com <ub...@gmail.com> #23
Thanks for the fix.
I'd think that MediaSessionCompat needs a similar fix, based on the leak traces (MediaBrowserServiceCompatLeak4.txt & MediaBrowserActivityLeak.txt) and PY's comments. You can repro MediaBrowserActivityLeak.txt by running the service in the same process as the Activity.
I'll ping PY about possibly chiming in on the code review.
aq...@google.com <aq...@google.com> #24
The change has now been merged. I'll now look into the media session compat issue, which seems to persist.
py...@squareup.com <py...@squareup.com> #25
Sorry for the late review. Not sure if you get notifications there, I left a comment:
TL;DR is that using weak refs isn't ideal, you could stick to a strong ref set to null from Service.onDestroy()
aq...@google.com <aq...@google.com> #26
Ack. Will implement the proposed fix.
ko...@gmail.com <ko...@gmail.com> #27
Есть ли утечка информации?
aq...@google.com <aq...@google.com> #28
Есть ли утечка информации?
According to translate: Is there any information leak?
No. This is a resources leak, no security issues here.
aq...@google.com <aq...@google.com> #29
Another fix for MediaSessionCompat...ExtraSession here:
Only one pending fix after this change is MediaSessionCompat...MediaSessionStub, after which I plan to mark this as fixed. Still, people should migrate to media3, but at least you can upgrade your MediaSessionCompat dep to get a quick fix of the leaks. Feel free to leave any comments here or in the patch.
aq...@google.com <aq...@google.com> #30
If there are more leaks to fix in androidx, please kindly file a fresh issue.
na...@google.com <na...@google.com> #31
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.media:media:1.7.0-beta01
ke...@gmail.com <ke...@gmail.com> #32
Hi im wondering if the leak happening in this issue on media3's issue tracker
is related to this.
By taking UAMP and having the MusicServiceConnection
be a Dagger @Singleton
, the MusicService
is leaked with a very similar stack trace that is exposed here, which contains only stacktraces from androidx.media
(until the MusicService
, that is):
====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS
References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.
43381 bytes retained by leaking objects
Signature: 80f093d135adc2b278b02ca2f66fbd46aaa36bea
┬───
│ GC Root: Global variable in native code
│
├─ android.support.v4.media.session.MediaSessionCompat$MediaSessionImplApi21$ExtraSession instance
│ Leaking: UNKNOWN
│ Retaining 6,7 MB in 1826 objects
│ ↓ MediaSessionCompat$MediaSessionImplApi21$ExtraSession.this$0
│ ~~~~~~
├─ android.support.v4.media.session.MediaSessionCompat$MediaSessionImplApi29 instance
│ Leaking: UNKNOWN
│ Retaining 6,7 MB in 1825 objects
│ ↓ MediaSessionCompat$MediaSessionImplApi21.mSessionFwk
│ ~~~~~~~~~~~
├─ android.media.session.MediaSession instance
│ Leaking: UNKNOWN
│ Retaining 1,8 kB in 12 objects
│ mContext instance of com.example.android.uamp.media.MusicService
│ ↓ MediaSession.mContext
│ ~~~~~~~~
╰→ com.example.android.uamp.media.MusicService instance
Leaking: YES (ObjectWatcher was watching this because com.example.android.uamp.media.MusicService received
Service#onDestroy() callback and Service not held by ActivityThread)
Retaining 43,4 kB in 896 objects
key = 11c50fab-5b0c-4267-8c51-ad235a51d861
watchDurationMillis = 5391
retainedDurationMillis = 390
mApplication instance of com.example.android.uamp.UampApplication
mBase instance of android.app.ContextImpl
====================================
`
I really dont see how using @Singleton
is any different from the default:
companion object {
// For Singleton instantiation.
@Volatile
private var instance: MusicServiceConnection? = null
fun getInstance(context: Context, serviceComponent: ComponentName) =
instance ?: synchronized(this) {
instance ?: MusicServiceConnection(context, serviceComponent)
.also { instance = it }
}
}
The issue can be reproduced on this branch of my fork of UAMP:
Which uses Dagger Hilt and removes Cast for simplification.
To reproduce:
- Open UAMP
- Play something
- Swipe the app away in the task manager
- Music Service is leaked.
From this point restarting UAMP also reveals the issue because nothing is loaded as there will be two MusicService instances.
ke...@gmail.com <ke...@gmail.com> #33
Also note that the example uses media 1.7.0 so fixes above should be included already.
aq...@google.com <aq...@google.com> #34
@kelmer@gmail.com might be an issue with MediaSessionCompat, but we'll need a fresh ticket to look into this.
ke...@gmail.com <ke...@gmail.com> #35
Should I create that one then?
Description
The essential output from LeakCanary for API level 19:
* GC ROOT android.os.Handler$MessengerImpl.this$0
* references android.support.v4.media.MediaBrowserServiceCompat$ServiceHandler.this$0
* leaks com.bubenheimer.mbscl.BrowserService instance
For API level 25 (21-24 are equivalent):
* GC ROOT android.service.media.MediaBrowserService$ServiceBinder.this$0
* references android.support.v4.media.MediaBrowserServiceCompatApi24$MediaBrowserServiceAdaptor.mBase
* leaks com.bubenheimer.mbscl.BrowserService instance
com.bubenheimer.mbscl.BrowserService extends MediaBrowserServiceCompat.
My minimal app is at:
My fork of UniversalMediaPlayer with LeakCanary added:
To reproduce the issue, simply start the app, then hit the back button to close the Activity. The MediaSession gets closed at that point, and the Service is leaked.
The leak occurs also when using plain MediaBrowserService, not just the Compat variant.
I have seen MediaBrowserService get leaked in different ways when it is used more seriously (actually playing music then stopping it, showing and discarding notifications, handling user input, etc.), so when addressing this issue, please also review potential leaks in more complex use cases.
I am using the latest support library version (25.2.0) in my sample app, UniversalMediaPlayer uses 23.4.0. The leak is the same.