Status Update
No update yet.
Comments
je...@google.com
lu...@google.com
1. Abstraction - my app module doesn't need to know about anything other than my internal modules and doesn't interface directly with libraries
2. An Application is built for each process, which means that we now have a CameraXConfig.Provider for secondary processes like a crash reporting process, etc... ContentProvider is only created once across all processes (and can be set to create one per process for apps that need to configure the camera across multiple processes, which I'm positive are very rare)
TL;DR the recent trend has been to move away from Application as a source of configuration for a variety of benefits
mi...@mercurydevelopment.com
lu...@google.com
Bugjuggler:
lu...@google.com
mi...@mercurydevelopment.com
lu...@google.com
mi...@mercurydevelopment.com
Hi there,
We're actively looking at this and will provide another method to initialize.
lu...@google.com
Branch: androidx-master-dev
commit 9015f3cff4053ad56b8b34b0708e3fe13945187c
Author: Trevor McGuire <trevormcguire@google.com>
Date: Thu Dec 05 18:21:19 2019
CameraX on-demand initialization through resources
Allows initializing CameraX without having to extend Application. A
default config provider can be specified through string resource or by
extending Application.
camera:camera-camera2 provides a default string resource which will be
included by default by the resource merger so users don't need to do
anything if they are ok with the default configuration.
Relnote: "Removed requirement that app must extend Application in order
to initialize CameraX. CameraX will now be initialized with a default
Camera2 configuration as long as the camera-camera2 artifact is included
in the application's build.gradle."
Bug: 146923574
Test: Integration tests are all successfully initialized and run
Change-Id: I58ff5c4440f9fec0afb3d9790f652dd91c2c84bd
A camera/camera-camera2/proguard-rules.pro
M camera/camera-camera2/src/main/AndroidManifest.xml
M camera/camera-camera2/src/main/java/androidx/camera/camera2/Camera2Config.java
A camera/camera-camera2/src/main/res/values/strings.xml
M camera/camera-core/src/main/java/androidx/camera/core/CameraX.java
A camera/camera-core/src/main/res/values/public.xml
A camera/camera-core/src/main/res/values/strings.xml
M camera/integration-tests/coretestapp/src/main/AndroidManifest.xml
D camera/integration-tests/coretestapp/src/main/java/androidx/camera/integration/core/CoreApplication.java
M camera/integration-tests/extensionstestapp/src/main/java/androidx/camera/integration/extensions/ExtensionsApplication.java
M camera/integration-tests/viewtestapp/src/main/AndroidManifest.xml
M camera/integration-tests/viewtestapp/src/main/java/androidx/camera/integration/view/ViewCameraXConfigProvider.java
M camera/integration-tests/viewtestapp/src/main/res/values/strings.xml
yu...@gmail.com
Hi All,
This is merged and will be available in the next release. Please take a look and let us know what you think. Thanks.
d....@pay-s.ru
da...@gmail.com
re:
da...@gmail.com
Well.. I also think this behavior is not so good.
What happens, if we want to use camerax in dynamic features module?
Is this really acceptable?
Rather, initialization using ContentProvider looks better.
Please re-consider on-demand initialization more. 🙇♂️
ra...@gmail.com
I notices this issue now. Well.. I also think this behavior is not so good.
As of alpha10, users no longer need to extend Application in order to initialize CameraX. Please let us know if this isn't working for you.
What happens, if we want to use camerax in dynamic features module?
I believe the current initialization mechanism introduced in alpha10 should work with dynamic features modules, but I'll admit I haven't yet tested it myself. If you have issues with dynamic features modules specifically, we would like to hear about it.
ro...@gmail.com
Camera function is not primary in my application.
So I wanna reduce app size possible.
And I choose dynamic features module.
Then camerax libraries should be used in a dynamic features module only.
I understand, CameraX always needs config setup in application. (if extend Application exists)
If I wrong, so sorry.
d....@pay-s.ru
I understand, CameraX always needs config setup in application. (if extend Application exists)
I think there may be some confusion here. To be clear, this behavior was changed in alpha10. Users no longer need to extend Application. CameraX will be initialized automatically if the user does not extend Application. Only in alpha07, alpha08, and alpha09 did users have to extend Application.
I believe this should work for dynamic feature modules as well, but have not yet had a chance to try it.
ya...@gmail.com
I will check again for dynamic features module with extended Application.
If some problem exists, then report through another issue.
Have a good day.
tr...@gmail.com
However, you should correct the order of camera2 dependency in build.gradle, because camera-view & camera-lifecycle will override the androidx_camera_default_config_provider string resource in build time with theirs camera-core dependencies
Correct the docs also pls
dependencies {
// CameraX core library using the camera2 implementation
def camerax_version = "1.0.0-alpha10"
// If you want to use the CameraX View class
implementation "androidx.camera:camera-view:1.0.0-alpha07"
// If you want to use the CameraX Extensions library
implementation "androidx.camera:camera-extensions:1.0.0-alpha07"
// If you want to use the CameraX Lifecycle library
implementation "androidx.camera:camera-lifecycle:${camerax_version}"
implementation "androidx.camera:camera-camera2:${camerax_version}"
}
bu...@gmail.com
It could be fixed on 7.4.2?
rj...@gmail.com
gi...@indiamart.com
li...@gmail.com
au...@gmail.com
I'm also have this same error with zoom in flutter
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:shrinkReleaseRes'.
> Multiple task action failures occurred:
> A failure occurred while executing com.android.build.gradle.internal.transforms.ShrinkProtoResourcesAction
> ParseError at [row,col]:[1,1]
Message: Content is not allowed in prolog.
> A failure occurred while executing com.android.build.gradle.internal.transforms.ShrinkProtoResourcesAction
> ParseError at [row,col]:[1,1]
Message: Content is not allowed in prolog.
> A failure occurred while executing com.android.build.gradle.internal.transforms.ShrinkProtoResourcesAction
> ParseError at [row,col]:[1,1]
Message: Content is not allowed in prolog.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 6m 28s
Running Gradle task 'assembleRelease'... 389.5s
Gradle task assembleRelease failed with exit code 1
zoom_native_sdk: ^0.3.3
Flutter 3.10.5 • channel stable •
java version "17.0.7" 2023-04-18 LTS Java(TM) SE Runtime Environment (build 17.0.7+8-LTS-224) Java HotSpot(TM) 64-Bit Server VM (build 17.0.7+8-LTS-224, mixed mode, sharing)
Gradle 7.6.1
Build time: 2023-02-24 13:54:42 UTC Revision: 3905fe8ac072bbd925c70ddbddddf4463341f4b4
Kotlin: 1.7.10 Groovy: 3.0.13 Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021 JVM: 17.0.7 (Oracle Corporation 17.0.7+8-LTS-224) OS: Windows 11 10.0 amd6
sa...@pocketfm.com
ar...@gmail.com
ng...@gmail.com
sg...@google.com
Manually updating the .xml files to not have a BOM should be a way to workaround this issue. Most text editors have a way of saving without a BOM.
Description
Our app uses Zoom SDK which contains files like this in res/raw folder:
As you can see there is an empty line after xml declaration.
Both AGP 7.3.0-beta03 and AGP 7.4.0-alpha04 can't build an app containing this file with the following exception:
When there is no files with an empty line after xml declaration ShrinkResourcesNewShrinkerTask executes correctly.
AGP 7.3.0-beta02 doesn't have this issue.
The issue is probably related to these changes:https://cs.android.com/android-studio/platform/tools/base/+/a01dac7c7fff60e3f98c90f50f5295415f623b80