Status Update
Comments
jm...@google.com <jm...@google.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!
fk...@gmail.com <fk...@gmail.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
jm...@google.com <jm...@google.com> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
[Deleted User] <[Deleted User]> #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.
[Deleted User] <[Deleted User]> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
pi...@gmail.com <pi...@gmail.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)
dr...@gmail.com <dr...@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).
lc...@gmail.com <lc...@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.
ci...@gmail.com <ci...@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)
}
}
}
em...@gmail.com <em...@gmail.com> #11
[Deleted User] <[Deleted User]> #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.
jm...@google.com <jm...@google.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
th...@gmail.com <th...@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.
ti...@gmail.com <ti...@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
jm...@google.com <jm...@google.com> #16
lc...@gmail.com <lc...@gmail.com> #17
jm...@google.com <jm...@google.com> #18
We're working through some decisions on our side. The implementation for pre-Marshmallow versions of Android will not use the AndroidKeyStore as per Tink's documentation.
lc...@gmail.com <lc...@gmail.com> #19
dr...@codetri.be <dr...@codetri.be> #21
sa...@gmail.com <sa...@gmail.com> #22
jm...@google.com <jm...@google.com> #23
ch...@gmail.com <ch...@gmail.com> #24
[Deleted User] <[Deleted User]> #25
rg...@gmail.com <rg...@gmail.com> #26
bo...@google.com <bo...@google.com>
ap...@google.com <ap...@google.com> #27
Branch: androidx-master-dev
commit 5dc65a7882dabeb8ea4c3bebb5e7d95aa113616a
Author: Nicole Borrelli <borrelli@google.com>
Date: Wed May 06 15:26:34 2020
Updates to support minSdkVersion=21
This creates a new "MasterKey" class that holds onto a key alias even
when that key may not exist in Android keystore.
Methods in EncryptedFile and EncryptedSharedPreferences also accept a
new MasterKey instance, in addition to the String "masterKeyAlias".
Relnote: "Add support for Android Lollipop (API 21+) via a new MasterKey
class. Because the Android keystore is not used prior to Android M (API
23+), developers should be aware that the keystore will _not_ be used
on Android L (API 21 and 22)."
Test: Existing and new tests pass
Bug: 132325342
Change-Id: I7c12d205273e4b652271865e53ff6c406632f407
M security/crypto/api/1.1.0-alpha01.txt
M security/crypto/api/current.txt
M security/crypto/api/public_plus_experimental_1.1.0-alpha01.txt
M security/crypto/api/public_plus_experimental_current.txt
M security/crypto/api/restricted_1.1.0-alpha01.txt
M security/crypto/api/restricted_current.txt
M security/crypto/build.gradle
M security/crypto/src/androidTest/java/androidx/security/crypto/EncryptedFileTest.java
M security/crypto/src/androidTest/java/androidx/security/crypto/EncryptedSharedPreferencesTest.java
A security/crypto/src/androidTest/java/androidx/security/crypto/MasterKeySecureTest.java
A security/crypto/src/androidTest/java/androidx/security/crypto/MasterKeyTest.java
M security/crypto/src/androidTest/java/androidx/security/crypto/MasterKeysTest.java
M security/crypto/src/main/java/androidx/security/crypto/EncryptedFile.java
M security/crypto/src/main/java/androidx/security/crypto/EncryptedSharedPreferences.java
A security/crypto/src/main/java/androidx/security/crypto/MasterKey.java
M security/crypto/src/main/java/androidx/security/crypto/MasterKeys.java
ap...@google.com <ap...@google.com> #28
Branch: androidx-master-dev
commit ad607178d97045fb1de089a875fd0ff4b80dece3
Author: Nicole Borrelli <borrelli@google.com>
Date: Tue May 26 22:09:26 2020
Pin androidx.collections version
Pin a specific version of androidx.collections for the library.
Bug: 132325342
Test: Existing tests pass
Change-Id: Id01320c4d42d739085eda365fefcdb1b6681d116
M security/crypto/build.gradle
gm...@gmail.com <gm...@gmail.com> #29
Could you please explain why keystore is not used on API 21-22? There are
Does it mean keysets are stored in cleartext on these devices? If yes, how can it be called "security"?
tr...@gmail.com <tr...@gmail.com> #30
tr...@gmail.com <tr...@gmail.com> #31
ka...@gmail.com <ka...@gmail.com> #32
ka...@gmail.com <ka...@gmail.com> #33
kr...@gmail.com <kr...@gmail.com> #34
My understanding of the change is that the secure prefs key is stored in cleartext for API < 23. This is of course a huge issue, and is actually worse than not supporting API < 23 at all, because developers may believe they have implemented secure encryption of this data when in fact they have not. It's false security. I am also a bit confused as to why an asymmetric keypair was not chosen for API < 23.
ou...@gmail.com <ou...@gmail.com> #35
Under Android M, security library uses Tink's AesGcmJce.encrypt() to encrypt the preference values.
So, actually, the values are not stored as clear text but encrypted text.
But it can't use KeyStore so IV's attached to value and encrypted key's bytes array is used as AAD.
As a result, yes, it's insecure.
Please let me know if I'm wrong.
bo...@google.com <bo...@google.com> #36
Before getting into details, the TL;DR is this: in order to improve your app’s security, it should only be allowed to run on devices that
Before Marshmallow (API 23), Android Keystore did not have support for symmetric keys. This, among
Without security updates, an actor can utilize exploits to gain access to encrypted data, _even when those secrets are protected by a TEE_².
Using the Jetpack security library makes it more difficult for an actor to access those secrets. Tink stores keys in the app's shared preferences, which are saved in the app's private directory. On devices which use fopen
the keys.
We felt that the functionality provided by the library would be helpful for developers, including developers who, for various reasons we understand, need to support users on devices that run older versions of Android.
¹ It's possible to verify the OS version and patch level with
ka...@gmail.com <ka...@gmail.com> #37
Tink stores keys in the app's shared preferences, which are saved in the app's private directory.
This is true. But if you consider this a secure directory, why bother having an EncryptedSharedPreferences.java
?
bo...@google.com <bo...@google.com> #38
Tink stores keys in the app's shared preferences, which are saved in the app's private directory.
This is true. But if you consider this a secure directory, why bother having an
EncryptedSharedPreferences.java
?
Saving information into an app's private directory is safe. EncryptedSharedPreferences
is intended to store small bits of data that are particularly sensitive. By using it, it increases the amount of effort required to extract that data from the device.
ss...@gmail.com <ss...@gmail.com> #39
bo...@google.com <bo...@google.com> #40
How secure is storing keys in Shared Preferences? Wouldn't a rooted user be able to lift the keys (even if they are encrypted)?
A rooted user can always access an app's data. It's more difficult when it's encrypted, and it's even more difficult when the key is stored in Key Store, but it's always possible for a rooted user to gain access to data on their device.
ss...@gmail.com <ss...@gmail.com> #41
bo...@google.com <bo...@google.com> #42
That doesn't really answer my question as to how secure Android's saving of keys to Shared Preferences is.
From reply #36:
Tink stores keys in the app's shared preferences, which are saved in the app's private directory. On devices which use
, those files are encrypted. The files are also protected by full-disk or file based encryption , so that other apps, including the user when connected via ADB or USB, cannot access them. So an app or user cannot simply dump or SELinux user permissions fopen
the keys.
Files stored in an app's private directory, which includes regular SharedPreferences
files, are generally secure.
ss...@gmail.com <ss...@gmail.com> #43
p....@anfe.ma <p....@anfe.ma> #44
Woudn't it be logical to support encryption for Android 21 & 22 utilizing asymmetric keys?
Like suggested here:
> There are known workarounds which allow generation of symmetric keys backed by Android Keystore on API < 23 by generating symmetric keys using different provider (Bouncy Castle), encrypting them with private key from asymmetric keypair stored in Android Keystore (assymetric keys are supported by Android Keystore from API >= 19) and storing them in internal storage. Such workarounds should be implemented in
>
da...@gmail.com <da...@gmail.com> #45
Hi, does the library support migration from Android 21 (Lollipop) and Android 23 (Marshmallow)?
In other words, if I ship an app using androidx.security 1.1.0-alpha01 / 1.1.0-alpha02 on a lollipop device, what will happen when (if) the device is updated to android 23?
Will the data be migrated to the usage of the masterkey?
thanks!
bo...@google.com <bo...@google.com>
jo...@gmail.com <jo...@gmail.com> #46
4b...@gmail.com <4b...@gmail.com> #47
Any news on this?
Description
And saw that the minsdk support for jetpack security library is Android 6+(API 23+). Would it be possible to support from Android 4.4.x(API 19+) as currently for my project (a govt national identity application), we need to support 95% of the devices out there.