Assigned
Status Update
No update yet.
Comments
jh...@gmail.com
Same here. I have links in a local html file referencing file:///android_res/drawable/ and on all gradle build flavors using another applicationId (added suffix) the Webview only shows broken links.
This behaviour seems not to be connected solely to Android 5.0 since it occurs on Android 4.4.4 too (tested with current cyanogenmod 11 build).
This behaviour seems not to be connected solely to Android 5.0 since it occurs on Android 4.4.4 too (tested with current cyanogenmod 11 build).
vi...@google.com
As a hotfix I added the following code to the gradle buildscript, which generates an additional R.java with changed java package for every flavor. I don't like this solution though.
android.applicationVariants.all{ variant ->
variant.javaCompile.doFirst{
copy {
from "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/R.java"
into "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${variant.buildType.name }/"
}
File rFile = file("${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${variant.buildType.name }/R.java")
String content = rFile.getText('UTF-8')
String newPackageName = "com.example.application.${variant.buildType.name }";
content = content.replaceAll(/com.example.application/, newPackageName)
rFile.write(content, 'UTF-8')
}
}
android.applicationVariants.all{ variant ->
variant.javaCompile.doFirst{
copy {
from "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/R.java"
into "${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${
}
File rFile = file("${buildDir}/generated/source/r/${variant.dirName}/com/example/application/${
String content = rFile.getText('UTF-8')
String newPackageName = "com.example.application.${
content = content.replaceAll(/com.example.application/, newPackageName)
rFile.write(content, 'UTF-8')
}
}
jh...@gmail.com
I've recenly encountered this issue and I must say it's quite a nuisance. Searched half of the Internet just to find out that the problem lies in Gradle's applicationIdSuffix :). I think this bug should be reported to Android SDK Build Tools devs, because only they can do something about it.
jh...@gmail.com
IMHO it's the case of Android platform problem. Resources are packed, WebView tries to load them from wrong place. It's not build tools that put them in wrong place.
And by the way it's very frustrating bug.
And by the way it's very frustrating bug.
jh...@gmail.com
[Comment deleted]
vi...@google.com
[Comment deleted]
jh...@gmail.com
The applicationIdSuffix/packageName/etc seem to be a Gradle-specific concept that applies only at build time.
At runtime, the only way WebView has to identify your app is the actual package name of the APK, and that will be the full string with the suffix included. The package that was used at compile time when generating the R class is not stored in the APK, and there's not really any way for WebView to know what it was as far as I know.
At runtime, the only way WebView has to identify your app is the actual package name of the APK, and that will be the full string with the suffix included. The package that was used at compile time when generating the R class is not stored in the APK, and there's not really any way for WebView to know what it was as far as I know.
vi...@google.com
[Comment deleted]
jh...@gmail.com
Isn't the package name attribute in the root node of the AndroidManifest preserved when an app is packaged? That would be the correct package to use when loading the R class
vi...@google.com
I don't think so. You could check what's actually in your packaged APK with "aapt dump xmltree <apkfilename> AndroidManifest.xml" - if it's not there, then WebView can't get to it at runtime either.
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.
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.
Description
Problem
JNI calls fail on certain objects when a native function invoked by Java in a newly created Java thread. My application attempts to mimic
Tested Devices:
Crash Output
Description
-- A DocumentProvider creates an IO thread when
openDocument()is called.-- I use ParcelFileDescriptor pipes because the files don't exist on disk, and it seems like the only way.
-- The IO thread calls a native read function, then from JNI-env a Java read method is invoked.
-- This should work, but for some reason some JNI objects are invalid in that IO thread (started from Java).
-- I have checked my code, and I don't think it's the issue here. Some notes:
thizinstance passed to the JNI-env).Steps to Reproduce
Coming soon... I'm creating a separate app that reproduces the issue.
What should happen
The JVM shouldn't crash.
Additional Notes
Could the references to the Java objects become invalidated once the DocumentProvider thread returns, leaving the IO thread running? I don't know the innards of ART enough (types of object references, etc..) to figure it out.
Suggestion
It'd be nice to be able to serve local/remote filesystems over kernel NFSD + DocumentProvider.