build/core/base_rules.mk:166: *** system/core/allwinner_a10_core/adb:
MODULE.HOST.EXECUTABLES.adb already defined by system/core/adb. Stop.
I can understand that there is a conflict between the ICS source code's adb and the adb provided by the actual board is leading to the conflict.
I want to know where and what file i have to change to resolve this conflict,i.e, tell the compiler which adb to use. (more generically which library to use, as i know this is a generic problem)
I wish the compilation process was explained better by google's reference documents!
Related
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
I hit this error and found no hits for the error message, so I thought I'd share the solution I came up with to save anyone else facing the problem repeating my work.
When writing a new Android library (apklib) for use in a (large) application, I'm getting the following error during dexing when I add my new project as a dependency:
trouble writing output: Too many field references: 70185; max is 65536.
You may try using --multi-dex option.
References by package:
<...long list of packages with field counts elided...>
The particular build step it fails on is:
java -jar $ANDROID_SDK/build-tools/19.0.3/lib/dx.jar --dex \
--output=$PROJECT_HOME/target/classes.dex \
<... long list of apklib and jar dependencies elided ...>
Using --multi-dex as recommended by the error message might be a solution, but I'm not the owner of the application project and it already has a large complex build process that I would hesitate to change regardless.
I can reproduce this problem with a no-op test library project that has literally no fields, but in the error output it's listed as having 6000+ fields. Of the packages listed in the error output, there are a handful with similar 6k+ field counts, but then the vast majority have more plausible <1k field counts.
This problem is similar to the "Too many methods" problem that Facebook famously hacked their way around. The FB solution seems insane, and the only other solutions I've found (e.g., this Android bug ticket, or this one, this SO answer, this other SO answer) all involve changing the main app's code which is well beyond the scope of what I want to do.
Is there any other solution?
The solution was to change the package in the AndroidManifest to match the main application's package.
A manifest like this:
<manifest package="com.example.testlibrary" ...
resulted in 6k+ fields and build failure. Changing it to match the main application's package
<manifest package="com.example.mainapplication" ...
resulted in the project building successfully.
Note that only the package in the manifest is changing, I did not make any changes to the library's Java source or its layout (the Java package was still com.example.testlibrary with directory structure to match).
I hypothesize that the different package name is causing all the Android fields to be included again under that package. All the packages in the error listing with 6k+ fields had a different package name than the main application.
I also (later, grr), found this blog post which details the same problem and the eventual same solution.
While compiling native code-base, I'm getting the following error -
<NDK-HOME>/platforms/android-17/arch-arm/usr/include/jni.h:235:68: error: expected ';' at end of member declaration
<NDK-HOME>/platforms/android-17/arch-arm/usr/include/jni.h:235:70: error: '\__NDK_FPABI__' does not name a type
...
With tons of repetitions.
Platform related details are as below -
Native OS: Windows 7 (64 bit) with Cygwin64
NDK Version: r9c
A similar problem has been reported here. However, even after modifying LOCAL_CFLAGS, I couldn't find the intermediate files as suggested.
Was wondering if some of you have faced this problem already and if so, do you guys have a work-around for this?
Alright, finally got rid of these __NDK_FPABI__ errors and my native code compiled just fine. Indeed, there were subtle hints in the intermediate files (*.i and *.ii) as suggested by Andrew in the link on my previous post; these are usually related to finding appropriate headers. Once relevant changes were made, things worked like a charm.
Few things I learned while debugging this issue -
The problem was related to header files. Certain headers were being picked up from /usr/include which otherwise should have been picked up from $NDK_HOME/platform/$ANDROID_VERSION/$ARCH/usr/include. Making necessary changes in the Android makefile fixed the issue for me.
Always resist the temptation of adding hot-fixes to NDK files. This will make your life a lot easier in the long run.
One should look for the intermediate files (*.i, *.ii, *s and few others) in $PROJECT_ROOT, instead of $PROJECT_ROOT/jni (assuming native code lies there).
The latest release of NDK, namely ndk-r9d fixes some of the issues with __NDK_FPABI__ related errors.
Hope this helps!
I am trying to compile some source code but when i run the command
make -f android-9-armv7.mk
I get the following error
android-9-armv7.mk:1: * missing separator. Stop.
This is the contents of the file above:
And I have set the IMAGINE_PATH variable as well, cant seem to figure it out.
link ../imagine/make/shortcut/common-builds/android-9-armv7.mk
Compiling instructions
http://code.google.com/p/emu-ex-plus-alpha/wiki/Compiling
Imagine is locaed at C:/Imagine
I don't know where you've taken the sources, but all the android-9-armv7.mk files from different projects on that git has following content:
../imagine/make/shortcut/common-builds/android-9-armv7.mk
...there is no link keyword, which probably is why you get this error.
Also, please be informed that you're building this on Windows machine while documentation clearly states that it's supported only on Linux and Mac OS X.