Status Update
No update yet.
Comments
pe...@gmail.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
sg...@google.com
cl...@google.com
cl...@google.com
Bugjuggler:
pu...@gmail.com
sg...@google.com
pu...@gmail.com
Hi there,
We're actively looking at this and will provide another method to initialize.
pu...@gmail.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
to...@yahoo.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.
bi...@google.com
hu...@google.com
re:
to...@yahoo.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. 🙇♂️
hu...@google.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.
hu...@google.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.
to...@yahoo.com
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.
hu...@google.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.
pu...@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}"
}
hu...@google.com
Please run the build with -Dcom.android.tools.r8.dumpinputtodirectory=. instead of -Dcom.android.tools.r8.dumpinputtofile, hopefully it will not be corrupted.
Make sure the build fails with The given file ... is located outside the root directory, and send us the dumpNNNN.zip files. Thanks a lot!
to...@yahoo.com Restricted
to...@yahoo.com
I can confirm #18 (thanks!, didn't think of trying that)
The failure only happens in debug builds (as uploaded in previous) while it builds fine and deploys without an issue in release builds.
hu...@google.com
That's great, thanks! (Release builds use a different pipeline, so it doesn't hit this code path.)
@Clément: Could you take a look at the dump above and see why in the desugaring graph (see com.android.tools.r8.D8Command.Builder#setDesugarGraphConsumer) D8 reports an edge to/from android.jar and whether that is expected?
If the behavior is correct in D8, I will fix this issue in AGP.
hu...@google.com
Update: By patching AGP with the input dump above, I can see that D8 reports the following dependency to AGP (via com.android.tools.r8.DesugarGraphConsumer#accept):
dependent = {ArchiveEntryOrigin@25758} "dump12086563528200/program.jar:com/.../.../channels/io/MyPipedInputStream.class"
dependency = {ArchiveEntryOrigin@25759} "Sdk/platforms/android-35/android.jar:java/io/InputStream.class"
Do we know why D8 reports that dependency given minSdk >= 24 (26 in the input dump)?
(It would be great to track this down before beta branching that's happening today.)
hu...@google.com
Steps to reproduce
Based on the input dump above, I've managed to reproduce this issue in a project (see attached):
- Create a project with
appandlib(Android library), using AGP 8.5.2 to 8.7.1, minSdk = 24+ - In
app, setisCoreLibraryDesugaringEnabled = trueandcoreLibraryDesugaring("com.android.tools:desugar_jdk_libs_nio:2.1.0") - In
lib, create a class that implementsjava.io.InputStreamorjava.io.PipedInputStream:
class ExampleClass(pipeSize: Int) : java.io.PipedInputStream(pipeSize)
- Run
./gradlew :app:mergeLibDexDebug, the build will fail with:
> Transform bundleLibRuntimeToDirDebug (project :lib) with DexingNoClasspathTransform
ERROR: D8: java.lang.IllegalStateException: The given file 'Sdk/platforms/android-34/android.jar' is located outside the root directory 'MyApplication/lib/build/intermediates/runtime_library_classes_dir/debug/bundleLibRuntimeToDirDebug'
Root cause
The issue is a combination of 2 factors:
- AGP doesn't expect desugaring dependencies between project's classes and
android.jar - D8 in some cases reports dependencies between the
ExampleClassabove andjava.io.InputStream(RetargetInterface)inandroid.jar
Workarounds
- Use
coreLibraryDesugaring("com.android.tools:desugar_jdk_libs_nio:2.0.4")instead of2.1.0+
Fix
- AGP: Ignore dependencies between project's classes and
android.jar - D8: Investigate root cause #2 and see why the behavior is inconsistent between
desugar_jdk_libs_nio:2.0.4and2.1.0+
hu...@google.com
- AGP: Ignore dependencies between project's classes and android.jar
We've done this in
Thanks a lot for this report and for helping us debug this issue!
Follow up
I'm closing this issue now, but it would be great if R8 team could verify the following, as it may indicate some bug in D8.
- D8: Investigate root cause #2 and see why the behavior is inconsistent between desugar_jdk_libs_nio:2.0.4 and 2.1.0+
ch...@google.com
Bugjuggler: wait until 20241120 -> clementbera
an...@google.com
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug Feature Drop | 2024.2.2 Canary 9
- Android Gradle Plugin 8.8.0-alpha09
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
ch...@google.com
I opened
pu...@gmail.com
Confirming it is fixed in Canary 9.
However, Canary 9 introduced a new unrelated issue for me:
to...@yahoo.com
I don't get the error described, but any source code changes are not reflected when I hit "Debug". I have to manually build first.
I added myself to the newest issue...
cl...@google.com
Could you confirm whether it is possible to have a (desugaring) dependency between the project's classes and android.jar when minSdk >= 24?
That is possible when using desugared library. Most desugaring happen below 24, but some methods are desugared up to latest android.
I see java.io.InputStream#transferTo(java.io.OutputStream) is desugared with desugared library up to android 32 so that makes sense.
to...@yahoo.com
meerkat / agp 8.9.x and suga 2.1.3 .... seems to build again ok.
thanks!
Description
Build failure after upgrading the desugar library to 2.1.0 It works in AGP 8.4.x.