Status Update
No update yet.
Comments
lb...@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).
ra...@google.com
vi...@google.com
lb...@gmail.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')
}
}
al...@google.com
lb...@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.
Description
implementation 'androidx.core:core-ktx:1.8.0'
implementation 'com.google.android.material:material:1.8.0-alpha01'
implementation 'androidx.constraintlayout:constraintlayout:2.1.4'
implementation 'androidx.navigation:navigation-fragment-ktx:2.5.1'
implementation 'androidx.navigation:navigation-ui-ktx:2.5.1'
- Steps to reproduce the problem (including sample code if appropriate).
1. Have a search MenuItem, along with some way to show Dialog and DialogFragment. In the Dialog, offer a way to invalidate the menu .
As this is quite a lot of boilerplate, sadly, I've prepared a sample project.
2. Open the search, type something, and show the Dialog. Close it, and see that the search query stayed.
3. Open the search, type something, and show the Dialog. Choose to trigger invalidation of the menu. Now see that it has reset the search, sadly. This could be a bug, but if not, please let me know how to invalidate without resetting the query.
4. Open the search, type something, and show the DialogFragment. Close it.
- What happened.
The search query gets reset after just closing the DialogFragment. It doesn't get reset when closing the Dialog.
- What you think the correct behavior should be.
Shouldn't reset at all. Doesn't matter if it's a DialogFragment or a Dialog.
- Is this a security related issue? Yes/No
No