Assigned
Status Update
No update yet.
Comments
vi...@google.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).
ma...@marcardar.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')
}
}
vi...@google.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
With the recent deprecations of methods like
RemoteViews.setAdapter(Int, Intent)andAppWidgetManager.notifyAppWidgetViewDataChanged(), I've been exploring migration to the newerRemoteViews.RemoteCollectionItemsAPI (Android 12+).However, some of my lists contain hundreds or even thousands of items, leading to a TransactionTooLargeException and causing the widget to become unresponsive. The only viable workaround appears to be limiting the number of displayed items—which isn't ideal, especially for a stack widget.
I've already switched to using image URIs instead of bitmaps, which helps for small lists, but doesn't resolve the issue for lists exceeding 100 items.
One potential approach I considered is tracking the stack position within the content provider supplying the images and using that to dynamically shift a rolling window (e.g., 10 items at a time). This could work with stable IDs, but ideally, such functionality should be built into the framework. This approach would offer the best of both worlds between the older
RemoteViewsFactoryAPI and the newerRemoteViews.RemoteCollectionItemsAPI.Could you provide an officially supported, non-deprecated way to handle large lists in home screen widgets?