Im new with gradle builds and dont understand why im not getting any of the LOGD statements included in logcat.
In the ccl, in gen/ccl/BuildConfig.java , i show:
public final static boolean DEBUG = true;
AFAIK that should be sufficient to include the ccl's logs in logcat but they are not there.
I used ./gradlew installDebugTests and installDebug to install the debug apk.
It shows log statements from the sender app but not from the ccl.
Earlier i built with ant and got all the ccl log statements just fine but cant figure out gradle.
That is caused by a bug in gradle that doesn't propagate that.. There is no trivial work around for that, and the gradle folks say it is non-trivial to fix it. What I personally do in my local repo is that I add "true ||" to the if-clause of the LOGD block to get that working in my local repo. Here is a reference to the bug: https://code.google.com/p/android/issues/detail?id=52962
Related
The problem
I'm trying to debug native (c++) code that is called from Java code (MainActivity.OnCreate) in simple android application. I'm using lldb for debugging and build the native code using cmake.
The debug works as expected until I try to step into native language function, then one of these happens:
1. The debugger steps into the function and allows making further steps, but there is no cursor, no normal stack trace, and no variable watches. The only thing in stack trace is the name of the cpp file and memory adress (instruction pointer maybe?) that increases with every step that I take. It looks to me as no debug symbols were loaded.
2. The step suceeds as it should and for a brief moment I can catch a glimpse of correct stack trace. But then the lldb crashes, the stack changes and the cursor is at art_sigsegv_fault. When I continue, I simply get a message that debugger was disconnected. The app continues to run as it should.
Additionally, I've noticed that at the moment of crash the debugger attempts to collect data from variables and never actually suceeds. The variables that are successfully resolved are a JNI pointer and jobject, while the others are jstring.
Miliseconds before the crash:
After the crash:
What I've tried
Made sure that symbols are not stripped from .so files, by adding
packagingOptions{
doNotStrip "**/*.so"
}
Made sure that CMAKE_CXX_FLAGS have -O0 -ggdb in them (no code optimization, debug compile)
Made sure that in Project Structure there is debug build, with properties Debuggable, Jni Debuggable, and Renderscript Debuggable set to true.
I believe that I've tried all the possible options that I've found here, hence a new question that may seem repetitive at first.
I am running into a problem while working on unit testing my system that I don't even know how to approach debugging. My code operates either on a linux machine with mock input or on an android device. I am using Google Test to run unit tests on it. I have it set up so that a call to "$ make all" will run my unit tests on both the linux machine and through adb shell on my device. This part is working fine.
However, when I introduce a test with EXPECT_DEATH(...) in it, the linux build runs the same as usual but the android build stops at that test and appears to freeze (I have to Ctrl + C to stop execution). As I said, I'm not at all sure how to try to fix this problem as I can't seem to get any output or error messages from it.
If you have any suggestions please let me know. If there is critical information I'm leaving out about my build, comment and I can add that in.
Edit:
When I run the function that I'm expecting to die outside of EXPECT_DEATH the same behavior occurs. This indicates that the assert in the function is working and EXPECT_DEATH is not doing what it should to handle that.
Before: (Works fine on Linux build but not on Android build)
EXPECT_DEATH(pObj->fxn(deathlyParam), "");
After: (Same result on Android build; core dump error due to assert on Linux build which is what I would expect both times from the Android build)
EXPECT_EQ(pObj->fxn(deathlyParam), 0);
For reference, fxn() looks something like this:
int fxn(int param)
{
assert(param != deathlyParam);
...
}
In light of this, it looks more like assert is acting improperly and not causing the error it should be. Therefore, EXPECT_DEATH has nothing to expect.
OK I figured it out. The problem was indeed arising from the assert in my function and not from EXPECT_DEATH. I don't know if this is just a feature of the project I'm working on (which had been developed for some time before I got to it) or if it is true of any Android build but NDEBUG was undefined, as in a release build. When I added "APP_OPTIM := debug" to my Application.mk file, it worked perfectly.
I am still a little confused why an assert would seemingly halt execution when NDEBUG is undefined. Aren't asserts supposed to be ignored entirely in release builds?
Credit to this question and answer for the solution.
Currently trying to build android-5.1.0_r5. I've checked out the sources and made no modifications. However, when compiling I get the following error.
Checking API: checkpublicapi-current
out/target/common/obj/PACKAGING/public_api.txt:20: error 5: Added public field android.Manifest.permission.BACKUP
out/target/common/obj/PACKAGING/public_api.txt:82: error 5: Added public field android.Manifest.permission.INVOKE_CARRIER_SETUP
out/target/common/obj/PACKAGING/public_api.txt:106: error 5: Added public field android.Manifest.permission.READ_PRIVILEGED_PHONE_STATE
out/target/common/obj/PACKAGING/public_api.txt:116: error 5: Added public field android.Manifest.permission.RECEIVE_EMERGENCY_BROADCAST
******************************
You have tried to change the API from what has been previously approved.
To make these errors go away, you have two choices:
1) You can add "#hide" javadoc comments to the methods, etc. listed in the
errors above.
2) You can update current.txt by executing the following command:
make update-api
To submit the revised current.txt to the main Android repository,
you will need approval.
******************************
And diffing the public api txt files does indeed show a difference.
diff frameworks/base/api/current.txt out/target/common/obj/PACKAGING/public_api.txt
19a20
> field public static final java.lang.String BACKUP = "android.permission.BACKUP";
80a82
> field public static final java.lang.String INVOKE_CARRIER_SETUP = "android.permission.INVOKE_CARRIER_SETUP";
103a106
> field public static final java.lang.String READ_PRIVILEGED_PHONE_STATE = "android.permission.READ_PRIVILEGED_PHONE_STATE";
112a116
> field public static final java.lang.String RECEIVE_EMERGENCY_BROADCAST = "android.permission.RECEIVE_EMERGENCY_BROADCAST";
However, I cant figure out where those additional Public Fields are coming from. Any ideas?
Don't do 'make update-api' if you didn't touch anything. There additional apis came form frameworks/base/res/AndroidManifest.xml badly parsed by aapt that uses buggy system/core/libcore/String8.cpp##removeAll() they use memcpy but should be memmove for overlapping strings in memory.
This is issue on latest Debian (sid) or Ubuntu (16 maybe 15) build machines.
It's a google bug in libcore/String8.cpp. Fix is here:
https://android.googlesource.com/platform/system/core/+/dd060f01f68ee0e633e9cae24c4e565cda2032bd
This man found it (Michael Scott) and maybe some other people too. Here is his investigation: https://plus.google.com/+hashcode0f/posts/URHo3hBmfHY
Living on the Edge (of Ubuntu) ... can be painful!
I've been running Ubuntu 15.04 for a while now. It's been great
having a very current kernel alongside the latest improvements from
Ubuntu and Debian. (My past post on using zRAM ramdisk is one
example).
However, having the newest greatest toys also has it's downsides. I
recently spent 4 days troubleshooting a build break in Android which
started some time after March 25th. I'm guessing I updated packages
or inadvertently changed my glibc version.
The outcome was a build error during the checkapi stage of Android
build:
Install: /out/mydroid-ara/host/linux-x86/bin/apicheck Checking API:
checkpublicapi-last Checking API: checkpublicapi-current
/out/mydroid-ara/target/common/obj/PACKAGING/public_api.txt:20: error
5: Added public field android.Manifest.permission.BACKUP
/out/mydroid-ara/target/common/obj/PACKAGING/public_api.txt:82: error
5: Added public field android.Manifest.permission.INVOKE_CARRIER_SETUP
/out/mydroid-ara/target/common/obj/PACKAGING/public_api.txt:106: error
5: Added public field
android.Manifest.permission.READ_PRIVILEGED_PHONE_STATE
/out/mydroid-ara/target/common/obj/PACKAGING/public_api.txt:116: error
5: Added public field
android.Manifest.permission.RECEIVE_EMERGENCY_BROADCAST
**************************** You have tried to change the API from what has been previously approved.
To make these errors go away, you have two choices: 1) You can add
"#hide" javadoc comments to the methods, etc. listed in the
errors above.
2) You can update current.txt by executing the following command:
make update-api
To submit the revised current.txt to the main Android repository,
you will need approval.
This occurred on both of my Ubuntu 15.04 boxes and was present when
when build AOSP android-5.0.2_r1 and android-5.1.0_r1.
For those of you who are unfamiliar with this portion of the Android
build, the Android framework exports all of the public portions of the
API and makes sure that the current build matches up with what's
located under frameworks/base/api/current.txt. It does this by
parsing frameworks/base/res/AndroidManifest.xml and any of the current
device's overlay .xml files and processes items marked with various
flags in the comments above them:#SystemApi, #hide, etc. This
parsing and processing portion of the checkapi stage is done by a
binary "aapt" (Android Asset Packagng Tool). It's source is located
under frameworks/base/tools/aapt.
I started by checking for upstream fixes to the platform/build or
platform/frameworks/base projects. After striking out, I began
debugging the android build via the use of: "make checkapi
showcommands" and then manually running the commands with "strace" to
see how each binary was involved and what output it generated.
After the first few hours of debugging, it became apparent that
out/target/common/obj/APPS/frameworks-res_intermediates/src/android/Manifest.java
file had comments which were being corrupted when aapt was generating
it. I was able to make some manual changes to the AndroidManifest.xml
file and get the build to pass (removing extra portions of the
comments).
Digging deeper via strace and then looking at various static link
sources, I found that during the AndroidManifest.xml comments
processing the #SystemApi token was being filtered out via a
String8.removeAll("#SystemApi") function call. Experimentally, I
removed this part of the processing. Lo and Behold! The build
worked. Taking a closer look at the removeAll function, I was able to
pin point a memcpy function as the part of the function which was
causing corruption.
I then researched memcpy a bit and noted that you are not supposed to
use memcpy on overlapping memory addresses, instead memmove was
preferred, because it makes a copy of the source prior to any changes
being made to the destination. After changing the use of memcpy to
memmove the build was fixed and all was well with the world!
As a good player in the open source world, I immediately thought I
should upstream this incredible feat of debugging to the master branch
of system/core. BUT, alas! The fix has been in the master branch
since November 11th 2014! And hasn't been brought into any of the
current development tags! grumble
https://android.googlesource.com/platform/system/core/+/dd060f01f68ee0e633e9cae24c4e565cda2032bd
I've since contacted the Google team about this change and let them
know of my experience in hopes that we may yet see this patch in
future release tags of Android.
Conclusion: apparently glibc is undergoeing some changes and some of
those have now filtered onto my Ubuntu boxes. Where previously the
memcpy usage was incorrect but still usable, it now causes the build
break I was seeing.
If you see this kind of error in your Android builds, and you're on a
newish version of Ubuntu or Debian distrobution, you may want to try
this simple patch and see if it helps.
Hash
Big up himself!
I do see the entries in my r8 code so you are probably safe running make update-api, and when that finishes then run your make command as normal.
In case of creation of the blank project in AIDE on a pad 4.2.2 of the basic code, AIDE finds an error:
This method must return the value of type"
Also QuickFix suggest to correct it by 'return 0' adding before a penultimate bracket that in turn attracts besides an error
A void method can't return a value
Also suggests to remove digit 0. Application is compiled, but not launched, referring to an error in application...Any ideas, why is it so? AIDE versions I tried the different.
I had the same error and when i reinstalled the app it worked. Also make sure you dont have a patched apk. I had that error with a pirate patched apk. I installed the original app with the premium key apk. XD Hope this helps you!
This is an interesting bug of Eclipse. I am using:
Version: Indigo Release
Build id: 20110615-0604
Out of nowhere today, I set a breakpoint in my android app on Eclipse. When it reaches the code, debug (dalvik JVM) aborts and crashes:
Tried to execute code in unprepared class (followed by the class name)
If I don't set the break point, it will run through with no problem. I have searched through Google but found nothing so far.
Another note, where I set this breakpoint does not matter, it could simply be the 1st line of onClick() function, or anywhere else. The moment the app "pauses" due to the breakpoint, it crashes.
I run into the same issue; for me, the problem was solved by removing all of the watched expressions I had set up in the debugger (one of them was causing the problem).
I run into the same issue when used watch expression with static method of this (unprepared) class.
I solved this issue by removing this expression from expressions list.
I solved this issue by removing an unused import package.
actually the error message is saying "tried to execute code in unprepared class" (followed by the class name)
I am not using that class but it is imported.
Simply remove the import, and it works fine ....