API Change error when building AOSP 5.1
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.