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.
Related
When I run a unit test for a new created project then it shows me the wrong result (Says All Tests are passed).
If you see in the image below 4 is expected while 6+2 surely not 4.
Now when I run the same test from Gradle right menu. It shows me the correct result that test has failed.
Did I do anything wrong or is this an android studio bug?
Edit
Run configuration image
You need to add -ea option in the "VM options" box in your 3rd image. This is to enable assertion feature for the JVM. Without this -ea, JVM just ignore assertion statement.
When you run the test with gradle, it used a default configuration so that's why your test was run correctly.
When building Lollipop, I could compile my changes by running:
make clean-framework clean-services clean-services.core services.core services framework && make snod
However, this is not reliable for Marshmallow. Sometimes it works, and other times my changes will not be compiled. I have also seen this produce an unbootable build, forcing me to do a full make -j8, which takes almost an hour on my machine.
Am I missing a new build target? Any advice is greatly appreciated.
Thanks.
The reason my partial builds failed to boot was due to dex pre-optimization. When dexpreopt is enabled, you cannot recompile certain parts of the system image, since they are byte-aligned and optimized together at compile time. After disabling dexpreopt, and doing a make clobber && make -j6, I was able to do partial builds with no issues.
To disable dexpreopt, set the following variables in your terminal:
export WITH_DEXPREOPT=false
export DISABLE_DEXPREOPT=true
TIP: add the above to your build/envsetup.sh or your .bashrc so you don't have to remember each time.
TIP 2: There is also a DONT_DEXPREOPT_PREBUILTS, but I have never had a problem with that, so I leave it set to the default, which isfalse. If you set this variable to true, it will take an incredibly long time (easily over an hour) for the device to boot after your flash it, since it has to optimize everything first.
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.
Ok so first off,
Im brand new to android dev. This is my first attempt at any form of kernel anything. I have a limited knowledge of java and python, but no C.
I have a galaxy tab 4 sm-t330nu running 4.4.2. its running a qualcomm snapdragon 400 msm8226 cpu. im simply trying to do a test build with a vanilla kernel at this point. (also my build environment is the newest kali 1.1 and im loosely following the tutorial at https://github.com/offensive-security/kali-nethunter/wiki/Porting-Nethunter)
so i have all of the required dependencies (i hope), and ive downloaded my source from samsung opensource. unzipped and went through the available defconfigs. after finding "msm8226-sec_milletwifiue_defconfig" i decided it was the most likely candidate for my tablet. (when doing a custom recovery i remember it being "philz touch milletwifiue something)
Ive done my exports (arch= subarch= cross_compile=) and all seems well. When i run a build following exactly as the tutorial says (using the defconfig in their example as a test) i receive an error stating "must define variant_defconfig". So i instead do "make variant_defconfig=msm8974_sec_defconfig" and it builds great.
Now the issue:
When i change "msm8974_sec_defconfig" to my actual msm8226 i receive an error on every build that i cannot seem to workaround. (cut down for size)
CC arch/arm/kernel/armksyms.o
CC arch/arm/kernel/module.o
AS arch/arm/kernel/sleep.o
CC arch/arm/kernel/suspend.o
CC arch/arm/kernel/io.o
arch/arm/kernel/io.c: In function '_memcpy_fromio':
arch/arm/kernel/io.c:14:3: error: implicit declaration of function 'nop' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/kernel/io.o] Error 1
make: *** [arch/arm/kernel] Error 2
My exact bash line reads
make VARIANT_DEFCONFIG=msm8226-sec_milletwifiue_defconfig
Any assistance on clearing this up would be great
edit
although im not familiar with c, it seems to me that '_memcpy_fromio' is where the error lies. and my google searches tell me that the error is that a function is used without being declared. however i dont know if memcpy is a function? or is the function within class memcpy (dont know if c has classes just closest equivalent that i know of) how do i debug this code and declare what needs to be declared (more importantly, if this is a stock kernel thats used by thousands of devices, how can it possibly have an undeclared function?
/edit
found the answer! needed
#import linux/modules.h
#import linux/kernel.h
On my Windows 7 platform, I have the latest version of adt bundle (20140321) and ndk (r9d) installed. The installation is as clean as it gets. The environment variables NDK_ROOT, PATH, etc. are all defined properly.
The application that I am working on has some native code that gets built with armeabi-v7a ABI. The app platform is andorid-19. Project settings define build as "ndk-build NDK_DEBUG=1."
From Eclipe, when I debug my application on my samsung tablet as "Android Java Application," everything works as expected. However, when I try to debug the app as "Android Native Application," I get the following error:
Attempting to connect debugger to 'com.mycomp.myapp' on port 8604
gdbserver output:
Cannot attach to lwp 28275: Operation not permitted (1)
Exiting
Verify if the application was built with NDK_DEBUG=1
The application runs fine on the device though.
I have looked at various messages on stackoverflow. However, I could not find any concrete step to fix this problem. Would appreciate if you can guide me in the right direction. Regards.
I have same problem. After wasting some time I found that when I return my simple function without any operation problem does not occurs.
void dmpBuffer(char* msg, unsigned char* buffer, int buffLen)
{
//return;
char szDumpBuffer[128];
for(int i=0; i<buffLen; i++)
sscanf(&szDumpBuffer[i*2], "%02X", buffer[i]);
LOGE("%s:%s", msg, szDumpBuffer);
}
maybe it is because of memory problems.
Update:
As I had Guessed it was memory problem.
My BIG mistake was using sscanf instead of sprintf!!!
My problem solved.