Develop Reference

"android: can't find sdkmanager.jar"

I downloaded the Android SDK tools from https://developer.android.com/studio/index.html which gave me a zip file called tools_r25.2.3-linux.zip. Unziped, it produced a folder called tools, containing the sdkmanager, android. When I tried to run it, it failed with the error message above.
I set ANDROID_HOME to the tools directory, but it still failed.

It turns out that ANDROID_HOME needs to be set to the parent directory, with the contents of the zip file (a single directory named tools) contained within it. Once I did that, it worked fine. This seemed confusing enough to be worth adding to stackoverflow.

The zip file can be opened anywhere. The important thing is to leave the name "tools" and it's files intact.
Run the android program from the tools parent directory as:
$ ./tools/android
This will update the tools parent directory (the one from where you are running ./tools/android) with a number of folders and tools.
I name this parent directory sdk. I also place the whole directory (named sdk) in a folder by the name of the downloaded version.
Now for consistency of my programming environment I bind mount this sdk to a folder in the /opt directory so that it'll be available system-wide.
The hierarchy becomes:
/home/userid/android_r25.2.3/sdk
Now I make a folder in the /opt/ directory called /opt/android/sdk.
My /etc/fstab entry for this becomes:
/home/userid/android_r25.2.3/sdk /opt/android/sdk none bind
It's mounted with:
$ sudo mount /opt/android/sdk
The only thing that changes with new versions or new installs is the location of where the zip file is opened. replace the /home/userid/android_r25.2.3/sdk with where you extract the zipfile and nothing else would ever have to be changed.
The PATH variable will consistently become:
$ export PATH=$PATH:/opt/android/sdk/tools:/opt/android/sdk/platform-tools
And, of course, the eclipse android configuration becomes:
/opt/android/sdk
Using this as a consistent procedure makes reinstalls and installs on new machines very seamless... having only one variable that might change, and that is where the package is extracted.

One more issue is that one has to leave the name of the unzip result tools untouched and move it into a to be created directory in order to allow any version management (or leave it in your home directory if a information-free directory name like "tools" doesn't distrub you). Then set ANDROID_HOME like #JesseW explained.

unzip tools into e.g. ~/android-sdk, so it will live at ~/android-sdk/tools
then in ~/.bashrc
export ANDROID_HOME="$HOME/android-sdk"
ANDROID_TOOLS="$ANDROID_HOME/tools"
ANDROID_PLATFORM_TOOLS="$ANDROID_HOME/platform-tools"
export PATH=${PATH}:$ANDROID_TOOLS:$ANDROID_PLATFORM_TOOLS;
then run sdkmanager

Compile libpcap using Android NDK

I've been doing a lot of attempts to get libpcap compiled for Android, and I don't see any pattern or any progress worth writing down.
I have a very simple sniffer (that works fine in a MIPS linux) that uses libpcap, so I thought to myself oh, ok... no biggie... I'll just compile libpcap for Android (in the end, Android is just a Linux)... and here's where the problems started. I have no idea on how to compile libpcap using ndk-build and the Android.mk and all that infrastructure.
I have the Android NDK in a directory. That NDK has the toolchains built (I have a lot of directories under ~/Documents/Projects/Android_NDK/toolchains/ ) but none of the toolchains has libpcap available.
I've tried with two different libpcap version or... branches:
The Android one, which is the one I'd like to use,
https://android.googlesource.com/platform/external/libpcap/
and the regular one:
http://www.tcpdump.org/release/libpcap-1.5.3.tar.gz
All tries I've done have been very unsuccessful. I've seen the question Android NDK: Link using a pre-compiled static library which is similar, but I'm still getting various errors.
I have downloaded those pcap libraries to their own directories. Maybe is that the problem? Do I need to put the Android libpcap in some directory within the NDK root directory and re-create the toolchains?
I'm using NDK-r9 on a MacOSX 10.9.2 64bit.

Finally!!
After getting annoyed by the non existing headers in and stuff like that, I found this question, that pointed to a SVN repo (http://sourceforge.net/p/prueba-android/code/HEAD/tree/trunk/jni/) with a libpcap that compiled!
If someone else wants additional details on how my Android.mk and directory structure looks like, please add a comment and I'll extend this answer.

Please read an excellent article at http://blog.umitproject.org/2011/05/libpcap-for-android.html. There are instructions that will help you link to libpcap, but the most important takeaway is that you cannot use libpcap on non-rooted Android. So maybe it's not worth your effort.
On a rooted device, you can simply install a free sniffer like Shark for Root.

If anyone else is having problems compiling libpcap for Android using the NDK, there is version 1.5.2 here with a built Android.mk file in it: https://android.googlesource.com/platform/external/libpcap.git and instructions for compiling this using the NDK are here: http://ducbh.blogspot.co.uk/2013/12/cross-compile-libpcap-for-android.html . I can confirm this works using the current NDK (r10b)...although you may have to add AndroidManifest.xml (blank) and and Application.mk that points to your Android.mk file.
I don't think it would be that difficult to modify the .mk file for the current libpcap version (1.6.2)

In case anyone ends up here in 2022+. You can now cross-compile for Android from the official source. Steps:
First, setup the NDK:
Download Android NDK (I used r21e) and extract to a directory of your choosing:
$ cd ~
$ mkdir Android
$ unzip android-ndk-r21e-linux-x86_64.zip
Prepare the environment variables for cross-compilation by placing the commands below (replace <YOUR_USER>) into a file named setup_env.sh (can be saved anywhere):
export NDK=/home/<YOUR_USER>/Android/android-ndk-r21e
export TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/linux-x86_64
export TARGET=aarch64-linux-android
export API=21
export AR=$TOOLCHAIN/bin/$TARGET-ar
export AS=$TOOLCHAIN/bin/$TARGET-as
export CC=$TOOLCHAIN/bin/$TARGET$API-clang
export CXX=$TOOLCHAIN/bin/$TARGET$API-clang++
export LD=$TOOLCHAIN/bin/$TARGET-ld
export RANLIB=$TOOLCHAIN/bin/$TARGET-ranlib
export STRIP=$TOOLCHAIN/bin/$TARGET-strip
Now, build libpcap:
Download libpcap tar ball (e.g. https://www.tcpdump.org/release/libpcap-1.10.1.tar.gz)
Extract (in a directory of your choosing): tar xf libpcap-1.10.1.tar.gz
Prepare your env: source <path_to>/setup_env.sh
Change into the extract libpcap directory and configure: ./configure --host=aarch64-linux-android
I found the Makefile generated had the wrong linker set (line 48), so I had to change it to: LD = /home/<YOUR_USER>/Android/android-ndk-r21e/toolchains/llvm/prebuilt/linux-x86_64/x86_64-linux-android/bin/ld
Finally, build: make
This build worked for me with running tcpreplay on a rooted Android, hopefully it works for other purposes as well!

Renaming the Package Name inside an APK

I have created an AIR app that is currently on the market. To update the app, obviously I must keep the same package name. My first version's were packaged using Eclipse with the ADT plugin.
Now to use AIR 3.0 Native Extensions (ANE) which were not available when I first developed the app, I currently must create my APK using AIR's command line tools. Unfortunately, these command line tools force you to have a package name that starts with the word "air". For example, I need the package name "com.example". AIR creates the package name as "air.com.example".
So now, I cannot update my app in the market since the package name has changed. Adobe has this horrific article to help you rename and remove the "air" in the package. I'm not a great programmer so this has really stumped me.
http://kb2.adobe.com/cps/875/cpsid_87562.html
Apparently this info is out of date or incorrect in a few areas.
I have completely stumbled at step 12 which uses apkbuilder:
apkbuilder final.apk -u -z resources.arsc -f classes.dex
I am getting this error message:
THIS TOOL IS DEPRECATED. See --help for more information.
java.io.FileNotFoundException: resources.arsc does not exist
I have used step 10 to create the new resources.arsc file. It clearly DOES exist and in the correct location. I tried using apkbuilder with other resources.arsc files taken from other projects. I still get the same error message.
Is there a chance in hell of this working? If anyone is interested in this, I have a zip file with a sample AIR apk, windows bat files for all the command line work, and all the needed utilities so they don't need to be downloaded. To get started you just need to change my path.bat to fit your system. And you need notepad++ (or an equivalent) to batch automate renaming the package name across several files.
bradwallacedesign.com/dktimer/renameApkProject.zip
Thanks so much!

this was done on a pc. i have no idea how to do this on a mac.
i don't recommend using this to remove the "air." from an air package name. If you do so, the user will not be prompted to download air on their device. the user will get an error message instead with no clue to the problem. of course you can use air captive runtime to solve this issue.
http://bradwallacedesign.com/share/renameAPK.zip
download and unzip my file (renameAPK.zip) to c:\renameAPK.
required files:
my file (renameAPK.zip) which contains the apkTool
java jdk/jre
android SDK
notepad++ (or an equivalent text editor that can rename across multiple files)
i made many bat files since i'm not sure how to combine them into one file. you will need to edit each one to change your path names and file names to work with your computer and your apk file.
i numbered all the bats in the order that i use them. once a command line is open, i type the number of the bat file i want then hit the tab key to automatically finish the name of the bat file then hit enter to run that bat file.
instructions:
double click `openCmd.bat to open a command line pointing to the directory with all your files.
0. run 0path.bat to set your path. (i can't remember now if the adobe air sdk is needed for this but i have it in my path. obviously, the JDK is needed and the android sdk for the jarsigner and zip align i think.)
1. run 1decompileAPK.bat to have apkTool decompile your app into a folder called UNZIPPEDapk
2. follow the instructions in 2editManifest & PackageName - Instructions (not a bat).txt to edit the manifest and package name using Notepad++ inside UNZIPPEDapk:
edit AndroidManifest.xml:
a. change package name from air.oldPackageName to newPackageName
b. edit other needed entries:
c. rename folder system inside "smali" folder so that it works with your new package name
for example:
if the old package name was: air/oldName then change the folders to match the new package name: air/newName
use notepad++ (or any editor that can find and replace text over many files)
d. ctrl+shift+f --- "Find in files"
find:
air/oldPackageName
replace with:
newPackageName
where:
all files in UNZIPPEDapk/smali
(i think there were over 200 replacements)
3. run 3buildDistFolder.bat to have apkTool build the new apk in the UNZIPPEDapk\Dist folder
4. follow the instructions in 4getMissingFiles - instructions.txt to reinstate the 2 missing files in the new build:
a. Two files were not built during 3buildDistFolder:
3buildDistFolder.bat built the new apk in the \UNZIPPEDapk\dist folder but it failed to copy 2 files:
(skipping hidden file 'C:\Users\computer\apkTool\UNZIPPEDapk\assets\META-INF
\AIR\extensions\com.adobe.mobile\META-INF\ANE\Android-ARM.classpath')
(skipping hidden file 'C:\Users\computer\apkTool\UNZIPPEDapk\assets\META-INF
\AIR\extensions\com.adobe.mobile\META-INF\ANE\Android-ARM.project')
grab these 2 files from your original apk and drop them into your new apk in the correct folder
b. copy yourApp.apk from DKTimer/Dist/ to root directory where your bat files are.
5. run 5signAPK.bat to sign the apk.
developer.android.com/guide/publishing/app-signing.html
6. run 6verifySigned.bat to verify the signing worked properly
7. run 7zipAlign.bat to align the apk file.
developer.android.com/guide/developing/tools/zipalign.html
You are finished at this point. Continue on if you want to test it on a device.
8. run 8installAPK.bat to install the apk on a usb connected device.
9. run 9remoteDebugger.bat if you want to use remote debugging.
i hope this helps someone. let me know if i forgot to include something.
also, if you know a better way to do this, please comment (such as how to combine this into 1 long pausing bat file...)

There is a simple environment variable you can set to disable the air. prefix easily. The following code exists in the Adobe AIR packager:
String optOut = System.getenv("AIR_NOANDROIDFLAIR");
if ((optOut == null) || (optOut.indexOf("true") == -1)) {
packageName = "air." + packageName;
}
So, simply set the AIR_NOANDROIDFLAIR environment variable to true, repackage your application, and it won't have the air. prefix. Google how to set environment variables in windows or mac for your particular OS version.
For example, I use the command-line compiler on Mac/Linux, so I run:
> export AIR_NOANDROIDFLAIR=true
> java -jar $AIR_HOME/lib/adt.jar -package -target apk-captive-runtime -storetype pkcs12 -keystore cert.p12 -storepass *** Main.apk Main-app.xml Main.swf
Warning: I don't know what implications this has. Per someone's note above, this may only be a good idea with captive runtime (but that's the default going forward from AIR 3.8).
Update: Renaun Erickson said it shouldn't cause problems.
Cross-posted here (slightly different question, same answer).

Having tried several apkRename tools, I found that they all failed for some app, such as com.android.browser on HTC device.
The reason is in apktool which does not correctly unpack apk file sometimes.
So, i create my own tool: https://github.com/sjitech/ApkRename
No need apktool, no need aapt, just java and jar utilities.
This utility directly modify AndroidManifest.xml so without recompile whole resource by apktool,
so it's clean.
Tested devices: 11 kinds (both android 4+, but 2.2+ should be no OK)
Tested OS: Mac OS X 10.9 and CentOS 6. (Cygwin with bash 4+ should be OK, but not tested yet)

I actually tried brad's approach and couldn't imagine having to go through the process EVERY TIME i compiled a release. so i did something else...i modified ADT so it doesn't insert "air." at the start and replaces it with a more useful extension like "com."
Here's a summary of the approach:
use:
jar xf adt.jar
to extract the adt.jar file to a directory on your desktop. you'll find it in {adobe SDK}/lib/
look for the file APKOutputStream.class
com/adobe/air/apk/APKOutputStream.class
Open it in a hex editor (eg, HxD is what i used). Search for "air." (without the quotes but including the dot).
Don't delete the entry. i tried, you can't, it corrupts the class and it won't run. What you can do, however, is replace "air." with "com." because it has the same number of characters and doesn't mess with the length of the file. The com prefix is a lot more useful to most of us.
save the modified APKOutputStream.class file and repackage with JAR. something like this:
jar cfm ..\patchedadt.jar ..\MANIFEST.MF *
you'll want to copy that MANIFEST.MF file from the subdirectory of the package called META-INF
Rename your patchedadt.jar to adt.jar and put it back in the lib directory. Works with the Flash Builder and all that garb.
Needless to say, when you're in there, you'll want to produce your package without a "com." prefix so you don't end up with com.com.your.package.name.
maybe there was an easier way, but i didn't know any better and no one else had an answer except to decompile the apk, modify it, and recompile and that didn't even work. so i figured i'll share what i did in case someone else stumbles on it later :)
jim

Android.mk rules to make a file.o from many files.txt then link it with other files.o produced from files.cpp

I'm porting a modem connection manager written in C++ from linux to gingerbread. This does not end up being an "app" with a "gui" that I would use a java wrapper with the NDK but a service that is called at boot from "init.rc". I found some not up to date docs related to android build system under build/core/. There you find some html files explaining the basics of Android build system and several "file.mk" which are some templates for common situation like creating a c++ executable, static libraries, shared library etc.
I place my tree with all the sources under external/myservice and it's meant to be compiled at the same time as Android itself. (I've already ported the kernel to my platform and it works, just the modem left to go)
In a subfolder in an Android.mk file, I have a bunch of ".cpp" files listed with the variable LOCAL_SRC_FILES := cppfile1.cpp cppfile2.cpp .... That will generate cppfile1.o cppfile2.o ...
I need to link those cppfile*.o with objfile.o to form a libfile.so. I found the rules on how to generate a libfile.so from a bunch of files.o.
Where things get complicated, is to port the "linux makefile" command to create objfile.o. Here is how it looks like
$(LD) $(LDFLAGS) -r -b binary -o QMIDB.o \
QMI/Entity.txt \
QMI/EnumEntry.txt \
QMI/Enum.txt \
QMI/Field.txt \
QMI/Struct.txt
Which means it is a linker job to merge a bunch of text file to make that objfile.o. That file is just a bunch of initialized data structure, there is no code to execute in it but it's pretty ugly to look at all files.txt with a text editor.
I have no clue how to integrate that in the Android.mk file. How can it be done? I'd even appreciate just a hint on where I can find more information. It is easy to find information on building Android applications but it's another story to find anything closer to Android/Kernel itself.

From the mk. file file you can easily get so file....
You need to use android Ndk setup and cygwin setup if you are using windows platform to genreate so file from your native code.
Firstly install and place ndk to a location...
Then install cygwin setup not default one check all features in the installation process (it a sort of linux terminal) as ndk-build command is recognized from linux terminal.
Now from your cygwin terminal get access to your project folder jni file.. or where mk is placed...
http://developer.android.com/sdk/ndk/index.html
Use the following referal how to run ndk-build command from cygwin terminal..
Now providing complete path of ndk we use the ndk-build command...
After that the complied code generates the .so file for our project...
Now what we are using System.loadlibrary command to use the so file i.e our native code can now be used.
Note to get so file form mk we need to complie using ndk setup.We can't directly copy paste so file to make our native code run.Also we we are using windows platfrom we will need to use cygwin setup to do that

Android NDK keeps looking for "g/David/..."

I installed the latest version of the Android NDK (r4) on Windows, plus a fresh installation of cygwin with the required packages, latest Android SDK, Eclipse + Android plugins.
Whenever I try to build any of the JNI code from cygwin (Be it the samples from the NDK, or a custom project), I'm getting:
$ make APP=demo
Android NDK: Building for application 'demo'
Compile thumb : demo_lib <= apps/demo/project/jni/demo.c
cc1: error: /cygdrive/g/David/ndk/build/platforms/android-3/arch-arm/usr/local/i
nclude: not a directory
cc1: error: /cygdrive/g/David/ndk/build/platforms/android-3/arch-arm/usr/include
: not a directory
make: *** [out/apps/demo/armeabi/objs/dmeo_lib/demo.o] Error 1
My name is not David, and I don't have a G drive.
Seems like this path is somehow hard-coded into this release. I tried looking for the string g/David in the NDK directory. It appears in many of the binaries, some .info files, as comment in some headers, and in two mkheaders.conf files:
<NDK>\build\prebuilt\windows\arm-eabi-4.2.1\lib\gcc\arm-eabi\4.2.1\install-tools\mkheaders.conf:
SYSTEM_HEADER_DIR="/cygdrive/g/David/ndk/build/platforms/android-3/arch-arm/usr/include"
and
<NDK>\build\prebuilt\windows\arm-eabi-4.4.0\lib\gcc\arm-eabi\4.4.0\install-tools\mkheaders.conf:
SYSTEM_HEADER_DIR="/cygdrive/g/David/ndk/build/platforms/android-3/arch-arm${sysroot_headers_suffix}/usr/include"
I changed both files to point to the correct path, but I get exactly the same error (with the original path).
I have limited experience with cygwin, unix, or make. Any ideas?

This is probably the symptom of an incomplete / broken NDK installation.
The gcc binaries always hard-code the original sysroot directory within their executable, but these are not normally found if appropriate system headers and libraries are provided otherwise. And they should.
Can you try re-downloading and re-unzipping the NDK package from the official site, and see if this fixes the problem ?

I had the same problem.
It's because maybe you have a G: drive for DVDRom or HDD (for me G: was the DVDROM). Problem resolved when i unactivate the G: drive ....

I have an (inactive) G: drive in Windows XP, too (some USB drive assigned for it). This prevents some builds with NDK r4, and I could not figure why sometimes the error pops up.
Anyway, here's the workaround:
prepare the alternative cygdrive path: mkdir c:\cygwin\ccc
use cygwin's mount -c ccc to change the cygdrive path prefix
create missing directories:
mkdir -f /cygdrive/g/David/ndk/build/platforms/android-3/arch-arm/usr/local/include
mkdir -p /cygdrive/g/David/ndk/build/platforms/android-3/arch-arm/usr/include
Now, you can run android-ndk-r4\ndk-build