Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
I am having the same problem. Whenever a new page is requested and rendered, a first white background shows briefly and causes flickering. Very unpleasant visual effect. Only happens when hardware acceleration is enabled.
ja...@gmail.com <ja...@gmail.com> #3
pls, tell me if you find any workaround for this (except for turning off HW acceleration)
Currently I don't know if this is possible
Currently I don't know if this is possible
co...@gmail.com <co...@gmail.com> #4
No workaround so far yet. Even the stock browser of Galaxy Nexus (LTE) suffers the same problem.This is especially bad for black background websites. However, Chrome beta is fine (apparently not using stock WebView?)
ja...@gmail.com <ja...@gmail.com> #5
Same problem on ASUS Transformer Prime TF201 (Android 4.0.3).
When we can expect some fixes here?
When we can expect some fixes here?
vs...@google.com <vs...@google.com>
an...@google.com <an...@google.com> #6
Expecting for the fix/workaround.. Very annoying. And browsing with disabled hardware acceleration is really horrible user experience. Google Please Fix!
an...@google.com <an...@google.com> #7
Did a workaround for this.
I added a view to my WebView, so this view is on top of the content. View has needed background color
Then, after some timeout I hide fake workaround view.
It's ugly, but works
I added a view to my WebView, so this view is on top of the content. View has needed background color
Then, after some timeout I hide fake workaround view.
It's ugly, but works
co...@gmail.com <co...@gmail.com> #8
Can you share the code snippet for the workaround? How do you switch from fake view to the correct view. Will it causes unnecessary latency.
ja...@gmail.com <ja...@gmail.com> #9
Here is what I did:
1. added workaround LinearLayout view to the WebView (WebView wv)
workaround = new LinearLayout(context);
workaround.setBackgroundColor(color);
wv.addView(workaround, ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT);
2. when I load any url I make it visible (also, note some variables: hidingWorkaround is boolean. handler is just android Handler)
workaround.setVisibility(View.VISIBLE);
handler.removeCallbacks(hideWorkaround);
hidingWorkaround = false;
3. when I get information about progress (in WebChromeClient) I initiate hiding progress:
if(isVisible() && !hidingWorkaround && workaround.getVisibility() != INVISIBLE) {
hidingWorkaround = true;
handler.postDelayed(hideWorkaround, 800);
}
where hideworkaround is runnable:
{
workaround.setVisibility(View.INVISIBLE);
hidingWorkaround = false;
}
That's all
Also, notice, this should be done only in ICS. so you have to check Android Version
1. added workaround LinearLayout view to the WebView (WebView wv)
workaround = new LinearLayout(context);
workaround.setBackgroundColor(color);
wv.addView(workaround, ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT);
2. when I load any url I make it visible (also, note some variables: hidingWorkaround is boolean. handler is just android Handler)
workaround.setVisibility(View.VISIBLE);
handler.removeCallbacks(hideWorkaround);
hidingWorkaround = false;
3. when I get information about progress (in WebChromeClient) I initiate hiding progress:
if(isVisible() && !hidingWorkaround && workaround.getVisibility() != INVISIBLE) {
hidingWorkaround = true;
handler.postDelayed(hideWorkaround, 800);
}
where hideworkaround is runnable:
{
workaround.setVisibility(View.INVISIBLE);
hidingWorkaround = false;
}
That's all
Also, notice, this should be done only in ICS. so you have to check Android Version
an...@google.com <an...@google.com> #10
Unfortunately, the only way to workaround the issue is to do something like the above, hiding the WebView during transitions. In ICS, a hardware accelerated WebView clears the frame buffer with white if it has content that hasn't finished rendering into tiles yet.
Thanks for the simple test case.
Thanks for the simple test case.
ra...@gmail.com <ra...@gmail.com> #11
Greetings.
Env info:
- OSX Yosemite
- NDK r10e (from May 2015)
- Toolchain 4.9
- ARM v7 .so
- Device: LG G3 - stock AOS, not rooted
Issue Description:
ndk-gdb fails when attempting to debug the .so on Lollipop device (LG G3)
Error reported:
[code]
ERROR: Non-debuggable application installed on the target device.
Please re-install the debuggable version!
[code]
However, the above error does not appear to be correct.
1. NDK_DEBUG=1 was used during .so compile
1. Above happens whether or not 'debuggable=true' in manifest (by default I omit this but added it long enough to verify)
1. Able to successfully debug the same .APK/.so on Nexus 7 (stock KitKat)
1. Able to successfully debug the same .APK/.so on Nexus 4 (stock/rooted KitKat)
~~
ndk-gdb -v logging indicates the following ABI information:
[code]
ABIs targetted by application: armeabi-v7a
Device API Level: 21
Device CPU ABIs: armeabi-v7a armeabi
Compatible device ABI: armeabi-v7a
[code]
The above ABI info looks fine. (Consistent with my expectations.)
~~
Examining the ndk-gdb (sh version not py)
Approx line 690 always fails
[code]
if [ "$COMPAT_ABI" = "$ANDROID_ARCH" ]; then
[code]
Reason:
[code]
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'arm'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'arm64'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'mips'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'mips64'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'x86'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'x86_64'
[code]
~~
I reverted back to NDK r10d.
But it had the same result - KitKat device debugs fine whereas Lollipop fails.
~~
I also tried the ndk-gdb version attached to response #11.
It yields same result (and is slightly older than the ndk-gdb used in r10e)
~~
I also tried debugging with NDK from the AOSP/platform/ndk master codeline.
(I figured Android devs must be debugging their apps successfully.)
However, it yields same result - debugs KitKat but fails Lollipop.
Or, at least, it fails on my LG G3 (stock image).
So I suppose the LG G3 might have something special about its AOSP image.
If I had more Lollipop devices I would try them too to rule out this being "LG G3 specific"
~~
So what step is missing?
Is the "stock LG G3" simply incompatible with AOSP NDK debugging?
Perhaps there is a necessary configuration setting missing from Application.mk (or Android.mk)?
Or maybe unzip of the NDK 10e release failed to unpack "./prebuilt/android-armeabi-v7a/gdbserver/gdbserver"?
Env info:
- OSX Yosemite
- NDK r10e (from May 2015)
- Toolchain 4.9
- ARM v7 .so
- Device: LG G3 - stock AOS, not rooted
Issue Description:
ndk-gdb fails when attempting to debug the .so on Lollipop device (LG G3)
Error reported:
[code]
ERROR: Non-debuggable application installed on the target device.
Please re-install the debuggable version!
[code]
However, the above error does not appear to be correct.
1. NDK_DEBUG=1 was used during .so compile
1. Above happens whether or not 'debuggable=true' in manifest (by default I omit this but added it long enough to verify)
1. Able to successfully debug the same .APK/.so on Nexus 7 (stock KitKat)
1. Able to successfully debug the same .APK/.so on Nexus 4 (stock/rooted KitKat)
~~
ndk-gdb -v logging indicates the following ABI information:
[code]
ABIs targetted by application: armeabi-v7a
Device API Level: 21
Device CPU ABIs: armeabi-v7a armeabi
Compatible device ABI: armeabi-v7a
[code]
The above ABI info looks fine. (Consistent with my expectations.)
~~
Examining the ndk-gdb (sh version not py)
Approx line 690 always fails
[code]
if [ "$COMPAT_ABI" = "$ANDROID_ARCH" ]; then
[code]
Reason:
[code]
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'arm'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'arm64'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'mips'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'mips64'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'x86'
Arch Test: COMPAT_ABI= 'armeabi-v7a' ANDROID_ARCH= 'x86_64'
[code]
~~
I reverted back to NDK r10d.
But it had the same result - KitKat device debugs fine whereas Lollipop fails.
~~
I also tried the ndk-gdb version attached to response #11.
It yields same result (and is slightly older than the ndk-gdb used in r10e)
~~
I also tried debugging with NDK from the AOSP/platform/ndk master codeline.
(I figured Android devs must be debugging their apps successfully.)
However, it yields same result - debugs KitKat but fails Lollipop.
Or, at least, it fails on my LG G3 (stock image).
So I suppose the LG G3 might have something special about its AOSP image.
If I had more Lollipop devices I would try them too to rule out this being "LG G3 specific"
~~
So what step is missing?
Is the "stock LG G3" simply incompatible with AOSP NDK debugging?
Perhaps there is a necessary configuration setting missing from Application.mk (or Android.mk)?
Or maybe unzip of the NDK 10e release failed to unpack "./prebuilt/android-armeabi-v7a/gdbserver/gdbserver"?
ra...@gmail.com <ra...@gmail.com> #12
Additional information although not sure if this helps.
My LG G34 is not rooted so added some debug logging to list contents of the "/data/data/com.my.app/lib " directory on the device. This apparently is the data directory in which the ndk-gdb script is seeking for presence of the gdbserver.
The file "/data/data/com.MyApp/lib/gdbserver" does exist properly.
However, ndk-gdb is choking when trying to find it.
~~
Since it appears there were other bugs in the return value checks from adb, I fiddled with the data directory and gdbserver lookups.
1. The data directory ('run-as') succeeded but the gdbserver lookup (straight 'ls') failed.
1. Side note: So, as far is it goes, it looks like the success/fail logic of 'adb_var_shell2' is working correctly.
~~
Meanwhile, it seems the ndk-gdb script is attempting to do something all of us wish we could do without needing to root the device. Namely, access the private storage directory of the app package without rooting or other shenanigans.
[code]
# Approx line 684
DEVICE_GDBSERVER=$DATA_DIR/lib/gdbserver
adb_var_shell2 GDBSERVER_RESULT ls $DEVICE_GDBSERVER
[code]
Generated the following on my LG G3 (these are log statements I added)
[code]
"## GDBSERVER existence checking for: '/data/data/com.my.app/lib/gdbserver '"
"## Yielded reult: '/data/data/com.my.app/lib/gdbserver : Permission denied'"
[code]
The above fails and kicks the script into the architecture compare test mentioned in my previous post (#12).
Oddly enough, the above succeeds on my Nexus 7. Although seems like maybe it should have also failed too? _shrug_
[code]
"## GDBSERVER existence checking for: '/data/data/com.my.app/lib/gdbserver '"
"## Yielded reult: '/data/data/com.my.app/lib/gdbserver '"
[code]
Regardless, the "quick fix" for me is to simply ignore this whole block and assume the gdbserver is present (since I know it is).
And, behold, the application .so is treated as debuggable by ndk-dbg on my Lollipop device.
Yay!
~~
So here are the changes I made to the ndk-gdb script. It's a hack, sure, but at least I can debug on my Lolipop LGG3.
[code]
# Approx line 684 of ndk=gdb
DEVICE_GDBSERVER=$DATA_DIR/lib/gdbserver
# This will fail on some devices permission denied (ie, All Lollipop? Just LG G3?) but I know my .so is debubggable
adb_var_shell2 GDBSERVER_RESULT ls $DEVICE_GDBSERVER
rcGdbSvr=$?
log "Real result of gdbserver query: '${rcGdbSvr}' (CHACK: forcing truth)"
rcGdbSvr=0
#if [ $? != 0 ]; then
if [ ${rcGdbSvr} != 0 ]; then
# ... block now skipped
fi
[code]
My LG G34 is not rooted so added some debug logging to list contents of the "/data/data/
The file "/data/data/com.MyApp/lib/gdbserver" does exist properly.
However, ndk-gdb is choking when trying to find it.
~~
Since it appears there were other bugs in the return value checks from adb, I fiddled with the data directory and gdbserver lookups.
1. The data directory ('run-as') succeeded but the gdbserver lookup (straight 'ls') failed.
1. Side note: So, as far is it goes, it looks like the success/fail logic of 'adb_var_shell2' is working correctly.
~~
Meanwhile, it seems the ndk-gdb script is attempting to do something all of us wish we could do without needing to root the device. Namely, access the private storage directory of the app package without rooting or other shenanigans.
[code]
# Approx line 684
DEVICE_GDBSERVER=$DATA_DIR/lib/gdbserver
adb_var_shell2 GDBSERVER_RESULT ls $DEVICE_GDBSERVER
[code]
Generated the following on my LG G3 (these are log statements I added)
[code]
"## GDBSERVER existence checking for: '/data/data/
"## Yielded reult: '/data/data/
[code]
The above fails and kicks the script into the architecture compare test mentioned in my previous post (#12).
Oddly enough, the above succeeds on my Nexus 7. Although seems like maybe it should have also failed too? _shrug_
[code]
"## GDBSERVER existence checking for: '/data/data/
"## Yielded reult: '/data/data/
[code]
Regardless, the "quick fix" for me is to simply ignore this whole block and assume the gdbserver is present (since I know it is).
And, behold, the application .so is treated as debuggable by ndk-dbg on my Lollipop device.
Yay!
~~
So here are the changes I made to the ndk-gdb script. It's a hack, sure, but at least I can debug on my Lolipop LGG3.
[code]
# Approx line 684 of ndk=gdb
DEVICE_GDBSERVER=$DATA_DIR/lib/gdbserver
# This will fail on some devices permission denied (ie, All Lollipop? Just LG G3?) but I know my .so is debubggable
adb_var_shell2 GDBSERVER_RESULT ls $DEVICE_GDBSERVER
rcGdbSvr=$?
log "Real result of gdbserver query: '${rcGdbSvr}' (CHACK: forcing truth)"
rcGdbSvr=0
#if [ $? != 0 ]; then
if [ ${rcGdbSvr} != 0 ]; then
# ... block now skipped
fi
[code]
Description
HostOS: Cygwin (on Win7)
Device: Nexus 5 (on Android 5.0.1)
NDK: version r10d
When running ndk-gdb I get the following error while it attempts to copy 'app_process' from the device:
## COMMAND: adb_cmd pull /system/bin/app_process obj/local/armeabi-v7a/app_process
remote object '/system/bin/app_process' not a file or directory
It appears that '/system/bin/app_process' is a symlink to either 'app_process32' or 'app_process64', which I understand is new to Android 5.0. But it will not pull down the dereferenced file (perhaps because it's on Cygwin/Windows?)
I injected the following code into 'ndk-gdb', line 750 to get it working... but this is obviously no good for the final product.
run adb_cmd pull /system/bin/app_process `native_path $APP_PROCESS`
### Injected Code ###
if [ $? != 0 ] ; then
run adb_cmd pull /system/bin/app_process32 `native_path $APP_PROCESS`
if [ $? != 0 ] ; then
echo "ERROR: Could not pull app_process from device/emulator."
exit 1
fi
fi
### End Injected Code ###
log "Pulled app_process from device/emulator."
As I said, I am new to NDK... so if I've done something wrong, I'd love to hear it! Thanks!