Status Update
Comments
aa...@hotmail.com <aa...@hotmail.com> #2
The attached Build Scan log shows that the emulator process crashed unexpectedly. Could you rerun your task with --info
and -Pandroid.experimental.testOptions.managedDevices.emulator.showKernelLogging=true
to get more information about the emualtor process logs?
ma...@gmail.com <ma...@gmail.com> #4
No idea why the scan does not contain log information, here you are:
[Deleted User] <[Deleted User]> #5
The link in --info
and -Pandroid.experimental.testOptions.managedDevices.emulator.showKernelLogging=true
, the emulator process output its kernel logging to stdout. Do you see any stacktrace or segfault in the log?
am...@google.com <am...@google.com> #6
That's strange, the repo and the build is public... But I attached the logs as file
am...@google.com <am...@google.com> #7
I looked into the logs and it turns out, the runner didn't have enough disk space. I guess the root cause is the Gradle update causing another Gradle major version (and its new transform-4) folder to cache was too much. Anyway, a better error message of the exit code of GMD would be helpful.
to...@google.com <to...@google.com> #8
Thanks for uploading the log! Yes, the emulator kernel log says the issue was the insufficient disk space:
2024-04-02T18:31:45.7078429Z ERROR | Not enough space to create userdata partition. Available: 7177.027344 MB at /home/runner/.config/.android/avd/gradle-managed/dev34_aosp_atd_x86_64_Pixel_2.avd, need 7372.800000 MB.
Also, I agreed that GMD should diagnose errors and can provide better messages.
Let me rename this issue's title to improve the error message for disk space error.
re...@gmail.com <re...@gmail.com> #9
I've added a fix that will surface all error messages from the emulator in the exception when it closes unexpectedly.
re...@gmail.com <re...@gmail.com> #10
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 Meerkat | 2024.3.1 Canary 2
- Android Gradle Plugin 8.9.0-alpha02
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!
to...@google.com <to...@google.com> #11
I haven't actually checked this as I don't have an android studio project handy currently (will try soon) but I suspect that Gradle passes the app name with the suffix appended to aapt with --package-name, which causes aapt to replace the name specified in your manifest with the one on the command line. The original name doesn't end up in the APK at all.
to...@google.com <to...@google.com> #12
This has confirmed what I wrote in my previous comments, unfortunately. What Gradle calls the package name (the name of the package that your Java sources and R class are stored in) is *not* the APK's actual package name that gets set at build time, and is *not* stored anywhere at all or accessible at runtime whatsoever. The APK is solely identified by the application ID with the suffix added, and the original package name is overwritten in the manifest. Android itself does not have this concept of the package name and application ID being separate; it's just a build-time trick Gradle is doing for you.
So, unfortunately, it doesn't look like there is any way for WebView to reliably know where your R class is. We might be able to add an API for the app to specify this in a future version (though I'm not entirely sure how that would actually work; it'd probably have to be a static method on WebView?), but that won't help you for existing OS versions, we can't add new APIs retroactively.
I think your only short-term options are to not use applicationIdSuffix or to not use file:///android_res/ in WebView. You could instead use a different URL (one that isn't handled by WebView itself), intercept it with shouldInterceptRequest, and provide the data by reading it from your resources yourself. I understand that that's not very convenient, but it seems like the only actual option here that works right now.
One thing WebView could do which would work in *some* cases is to just try to strip off components from the package name if the R class isn't found, going up one package at a time until we find it. That would work if you've just added a suffix like ".debug" - we'd fail to find com.example.debug.R and then try com.example.R instead. That still wouldn't work for any case where the package name is totally different, though (which gradle permits you to do). I'll look into whether this is safe to do and if so we could maybe add this in a future webview update, but it still won't fix the problem for users of pre-Lollipop Android versions (who don't get WebView updates), or for users who just don't have the latest webview update installed, so you're going to have to work around this problem in your app anyway to continue supporting those devices. :/
to...@google.com <to...@google.com> #13
[Deleted User] <[Deleted User]> #14
I think the whole scheme file:///android_res/ ideally should be deprecated in favor to android.content.ContentResolver.SCHEME_ANDROID_RESOURCE, which allows specify package and resId and used everywhere in Android except WebView.
What do you think?
to...@google.com <to...@google.com> #15
to...@google.com <to...@google.com> #16
This won't fix it for users with pre-L android versions, or who don't upgrade to at least WebView 53 once it's released, though, so you will not be able to rely on this as a full workaround :/
re...@gmail.com <re...@gmail.com> #17
to...@google.com <to...@google.com> #18
re...@gmail.com <re...@gmail.com> #19
L+ devices so, it might not solve the real issue, but it is sufficient for
me :)
de...@tangible.tech <de...@tangible.tech> #20
je...@gmail.com <je...@gmail.com> #21
to...@google.com <to...@google.com> #22
I'm going to close this bug as we aren't planning to do anything further to address this issue beyond the change made some time ago in #16 (and fixing it again after it broke in a more recent version)
ah...@gmail.com <ah...@gmail.com> #24
طوفان
ah...@gmail.com <ah...@gmail.com> #25
طوفان
sm...@gmail.com <sm...@gmail.com> #26
android { defaultConfig { applicationId "com.example.myapp" minSdkVersion 15 targetSdkVersion 24 versionCode 1 versionName "1.0" } ... android { defaultConfig { applicationId "com.example.myapp" minSdkVersion 15 targetSdkVersion 24 versionCode 1 versionName "1.0" } All this is fraud and money was stolen
pa...@gmail.com <pa...@gmail.com> #27
Issue solved
pa...@gmail.com <pa...@gmail.com> #28
Good
ns...@gmail.com <ns...@gmail.com> #29
Thank you so much.
aa...@gmail.com <aa...@gmail.com> #30
That's
Description
I have a applicationId and packageName org.myorg.myapp and use an applicationIdSuffix '.debug' for debug builds. The classloader is then looking for the class org.myorg.myapp.debug.R.raw, which does not exist because my R class is org.myorg.myapp.R.
The correct behaviour should be that the class {packagename}.R should be loaded instead of {applicationId}.R
I get this error on a Motorola XT1092 running android 5.0