Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
We're seeing a similar error in our code. Appears to be a combination of AGP 8.6.0 and Kotlin 2 needed to hit it.
private fun Intent.stripUnwantedFlags() {
// Explicitly remove the new task and clear task flags (Our browser activity is a single
// task activity and we never want to start a second task here).
flags = flags and Intent.FLAG_ACTIVITY_NEW_TASK.inv()
flags = flags and Intent.FLAG_ACTIVITY_CLEAR_TASK.inv()
// IntentReceiverActivity is started with the "excludeFromRecents" flag (set in manifest). We
// do not want to propagate this flag from the intent receiver activity to the browser.
flags = flags and Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS.inv()
}
All 3 lines then hit:
Must be one or more of: Intent.FLAG_GRANT_READ_URI_PERMISSION, Intent.FLAG_GRANT_WRITE_URI_PERMISSION, Intent.FLAG_FROM_BACKGROUND, Intent.FLAG_DEBUG_LOG_RESOLUTION, Intent.FLAG_EXCLUDE_STOPPED_PACKAGES, Intent.FLAG_INCLUDE_STOPPED_PACKAGES, Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION, Intent.FLAG_GRANT_PREFIX_URI_PERMISSION, Intent.FLAG_ACTIVITY_MATCH_EXTERNAL, Intent.FLAG_ACTIVITY_NO_HISTORY, Intent.FLAG_ACTIVITY_SINGLE_TOP, Intent.FLAG_ACTIVITY_NEW_TASK, Intent.FLAG_ACTIVITY_MULTIPLE_TASK, Intent.FLAG_ACTIVITY_CLEAR_TOP, Intent.FLAG_ACTIVITY_FORWARD_RESULT, Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP, Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS, Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT, Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED, Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY, Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET, Intent.FLAG_ACTIVITY_NEW_DOCUMENT, Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET, Intent.FLAG_ACTIVITY_NO_USER_ACTION, Intent.FLAG_ACTIVITY_REORDER_TO_FRONT, Intent.FLAG_ACTIVITY_NO_ANIMATION, Intent.FLAG_ACTIVITY_CLEAR_TASK, Intent.FLAG_ACTIVITY_TASK_ON_HOME, Intent.FLAG_ACTIVITY_RETAIN_IN_RECENTS, Intent.FLAG_ACTIVITY_LAUNCH_ADJACENT, Intent.FLAG_ACTIVITY_REQUIRE_NON_BROWSER, Intent.FLAG_ACTIVITY_REQUIRE_DEFAULT, Intent.FLAG_RECEIVER_REGISTERED_ONLY, Intent.FLAG_RECEIVER_REPLACE_PENDING, Intent.FLAG_RECEIVER_FOREGROUND, Intent.FLAG_RECEIVER_NO_ABORT, Intent.FLAG_RECEIVER_VISIBLE_TO_INSTANT_APPS
ja...@gmail.com <ja...@gmail.com> #3
The initial report (
However,
co...@gmail.com <co...@gmail.com> #4
Thanks for fixing! What release should we be able to verify the fix in? And is there any chance of a backport for 8.6.1?
vs...@google.com <vs...@google.com>
co...@gmail.com <co...@gmail.com> #8
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 Ladybug Feature Drop | 2024.2.2 Canary 2
- Android Gradle Plugin 8.8.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!
ja...@gmail.com <ja...@gmail.com> #9
The fixes for this issue are now also available in:
- Android Studio Ladybug | 2024.2.1 RC 1
- Android Gradle Plugin 8.7.0-rc01
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
an...@google.com <an...@google.com> #10
Sorry about that
ra...@gmail.com <ra...@gmail.com> #11
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
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!