Is there any way to have C/C++ compilers directly into the Android device ?
Something like I can adb shell the device and run gcc or agcc or something related to compiling C\C++ src files.
I googled, but there were just speculations, please help in this !
Thanks in Advance :) :)
Shoaib
If you install c4droid you can make an onboard executable by finding the gcc binary and calling it. I also have root on my phone.
On your phone or tablet:
Install c4droid(paid app) and additionally GCC plugin(free).
Install a terminal client. I use Better Term but there are free options as well.
find / -name gcc
/mnt/sdcard/Android/data/com.n0n3m4.droidc/files/gcc/bin/arm-linux-androideabi-gcc
cat > test.c
#include<stdio.h>
int main(){
printf("hello arm!\n");
return 0;
}
./mnt/sdcard/Android/data/com.n0n3m4.droidc/files/gcc/bin/arm-linux-androideabi-gcc test.c -o test
./test
hello arm!
Try C4droid
https://market.android.com/details?id=com.n0n3m4.droidc
or this app
https://market.android.com/details?id=GDE.Main
Related
I want to install compile Boost 1.61 with clang 3.6 for android with the NDK 11 but this software : https://github.com/moritz-wundke/Boost-for-Android isn't updated and doesn't support this versions.
I want to know if anyone has managed to this !
Thank you !
Build boost_1_62_0 for Android-21 under Windows64.
Assuming NDK installed to C:\Programs\Android\sdk\ndk-bundle and boost in c:\boost_1_62_0.
Install mingw: using msys2-x86_64 from MSYS2
Install build tools from mingw prompt (something like this):
$ pacman -S gcc binutils
Create android.clang.jam file in C:\boost_1_62_0\ with such text content:
import os ;
local AndroidNDKRoot = C:/Programs/Android/sdk/ndk-bundle ;
using clang : android
:
C:/Programs/Android/toolchain21/bin/clang++
:
<compileflags>-fexceptions
<compileflags>-frtti
<compileflags>-fpic
<compileflags>-ffunction-sections
<compileflags>-funwind-tables
<compileflags>-Wno-psabi
<compileflags>-march=armv7-a
<compileflags>-mfloat-abi=softfp
<compileflags>-mfpu=vfpv3-d16
<compileflags>-fomit-frame-pointer
<compileflags>-fno-strict-aliasing
<compileflags>-finline-limit=64
<compileflags>-I$(AndroidNDKRoot)/platforms/android-21/arch-arm/usr/include
<compileflags>-Wa,--noexecstack
<compileflags>-DANDROID
<compileflags>-D__ANDROID__
<compileflags>-DNDEBUG
<compileflags>-O2
#<compileflags>-g
<compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.9/include
<compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include
<architecture>arm
<compileflags>-fvisibility=hidden
<compileflags>-fvisibility-inlines-hidden
<compileflags>-fdata-sections
<cxxflags>-D__arm__
<cxxflags>-D_REENTRANT
<cxxflags>-D_GLIBCXX__PTHREADS
;
Setup boost from mingw prompt:
$ export NDK=/c/Programs/Android/sdk/ndk-bundle
$ echo ensure msi-installed Python is on path (not msys version):
$ export PATH=/c/Python27:$PATH
$ $NDK/build/tools/make_standalone_toolchain.py --arch arm --api 21 --install-dir /c/Programs/Android/toolchain21
$ ./bootstrap.sh --with-toolset=gcc
$ ./b2 --user-config=android.clang.jam threading=multi link=static \
runtime-link=static toolset=clang-android target-os=linux \
threadapi=pthread --stagedir=android --with-chrono \
--with-program_options --with-system --with-thread --with-random \
--with-regex
Yes, the repository you mentioned is apparently not maintained anymore. The author also seems not to answer any mails on the subject. If you look you'll see that each new boost version supported there required a lot of work (many special flags in the config files). That's presumably why he doesn't have time to maintain it any longer.
I also tried to update to 1.64 using a fork but gave up after countless error messages and instead used a different method based on a crystax script. Its simple and should work for pretty much any version. You can find the details and the script (simple and painless to execute) here: http://silverglint.com/boost-for-android/
Works with clang and gcc.
Also included is a sample app that shows you how to use the boost binaries thus built.
All, Forgive me I am familiar with the C program for the Android/Linux platform. Now I am trying to use the Sourcery G++ Lite Edition
for ARM to build my sample C program and deploy it to the Linux of the Android platform.
Below is the instructions what I follow.
So far it works fine. But I have something I didn't understand well. please review it . thanks.
The Source code is a hello world program.
#include <stdio.h>
int main(int argc,char * argv[])
{
printf("Hello, Android!\n");
return 0;
}
In the development machine command console. run the following commands line.
arm-none-linux-gnueabi-gcc hello.c -static -o hellostatic
adb push hellostatic /data/test
adb shell
cd /data/test
.hellostatic
Hello, Android!
So here is my question.
Can gcc build a executable file from a c source code file? Seems It doesn't need link tool. Is it right? thanks.
Can gcc build a executable file from a c source code file?
yes, of course.
Seems It doesn't need link tool?
no, I extract the following sentences from gcc manual,
GCC is capable of preprocessing and compiling several
files either into several assembler input files, or into one assembler input file; then each
assembler input file produces an object file, and linking combines all the object files (those
newly compiled, and those specified as input) into an executable file.
At default gcc will do complie and link operation, unless you type particular options such like:
gcc -c file.c
this will just compile file.c to file.o
or:
gcc -o file file.c
this will complie file.c to file.o and also link it to make a executable file finally.
Although yanchong had already gave the nice answer , I also found a good read from here. I think it will help to understand the concepts of Compile, Link and Build. Thanks.
I have a Device on which I installed Android Gingerbread 2.3.4
Here i want to run C executable file on android device
I am able to run android NDK application on this Device and it runs perfect.
But I want to run only one hello.c executable file on the Device.
/* #includes #defines ... */
int main(){
// Do something when this is executed
return 0;
}
Is there any way to compile this file with Android NDK tool chain so I can run this file's executable?
I found one thing here but this is not working for me. I am using Android NDK, Revision 7b for Linux.
There is no directory structure like this.
First, let me say that my answer is dependent on your using NDK r7b (it'll work for r7c as well) on Linux (change paths appropriately for other systems).
Edit: Last tested with NDK r8e on Linux and Nexus 4 with adb from SDK Platform-Tools Rev 18 on Windows 7 (latest as of 2013-07-25) without root access.
Yet Another Edit: Please read this question for altering my instruction for native binaries that need to run on Android 5.0(Lollypop) and later.
Go to $NDK_ROOT (The topmost folder of NDK zip when unzipped).
Copy $NDK_ROOT/samples/hello-jni directory as $NDK_ROOT/sources/hello-world.
Go to $NDK_ROOT/sources/hello-world.
Edit AndroidManifest.xml to give the application an appropriate name (This is optional).
Go to $NDK_ROOT/sources/hello-world/jni. This is where the source code is.
Edit hello-jni.c, remove all the code, and put in your hello world code. Mine is:#include
int main( int argc, char* argv[])
{
printf("Hello, World!");
return 0;
}
Edit Android.mk and change the line include $(BUILD_SHARED_LIBRARY) to include $(BUILD_EXECUTABLE). You can also change the LOCAL_MODULE line to the name you want for your executable(default is hello-jni)
Go back to $NDK_ROOT/sources/hello-world
Run ../../ndk-build to create the executable.
Copy it from $NDK_ROOT/sources/hello-jni/libs/armeabi/hello-jni to /data/local/tmp on the Android device and change it's permissions to 755 (rwxr-xr-x). If you changed the LOCAL_MODULE line in $NDK_ROOT/sources/hello-world/jni/Android.mk, the executable name will be the new value of LOCAL_MODULE instead of hello-jni. (All this is done via adb from the Android SDK.)
Execute the binary with full path as /data/local/tmp/hello-jni, or whatever you named it to.
And you're done( and free to start on the documentation in $NDK_ROOT/docs to get a better idea of what to do).
The best/easiest place to put a executable is /data/local. You'll also need to chmod the binary as executable. Often you'll also need to do this in two steps to get the binary from /sdcard/ to /data/local:
$ adb push mybin /sdcard/
$ adb shell
$ cp /sdcard/mybin /data/local/mybin
$ cd /data/local
$ chmod 751 mybin
Caveats:
Not all systems have cp. You can use cat if this is the case:
$ cat /sdcard/mybin > /data/local/mybin
Some systems don't allow write in /data/local for the "shell" user. Try /data/local/tmp
the "/sdcard" location is not executable, meaning that any file there is not executable at all.
the only way to "adb push" executable would be to put them in "/data/local", which should be writable for adb, and allow execution for anyone.
I recently had the same problem on a new nexus-5. I'd like to add that /data/local was not writable by the user ("shell", uid 2000) I got with adb shell. But putting the executable in the subdirectory /data/local/tmp/ worked fine.
In a nutshell,
First, to cross-compile your C code from your host machine, use NDK toolchain with sysroot option and position independent option -fPIE -pie.
$NDKROOT/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-gcc \
--sysroot=$NDKROOT/platforms/android-22/arch-arm64 -fPIE -pie main.c -o main
the arch part arrch64 or arch-arm64, the toolchain version part 4.9, platform version part android-22, and the binary format for your host machine darwin-x86_64 may vary by your environment.
Second, push your binary under /data/local/tmp and execute it from adb shell.
Is anyone using Google Breakpad for Android native code (NDK) ?
If so, could you elaborate on how to get it up and running (the client side that is).
The docs are very limited and don't mention Android at all. The build system contains android information though which make me think it shouldn't be a problem.
Sorry about that, I did the initial port but I didn't really document anything. However, one of the Chrome engineers did some work on the port and wrote a really nice README:
https://chromium.googlesource.com/breakpad/breakpad/+/master/README.ANDROID
There's also an NDK-compatible Android.mk file in there now, so if you're using the standard NDK build system it should be simple to incorporate Breakpad.
I also found a good example project for that.
As it is in the project you can set up Google Breakpad like:
extern "C" {
void Java_com_pluusystem_breakpadjavacall_MainActivity_initNative(JNIEnv* env, jobject obj, jstring filepath)
{
const char *path = env->GetStringUTFChars(filepath, 0);
google_breakpad::MinidumpDescriptor descriptor(path);
exceptionHandler = new google_breakpad::ExceptionHandler(descriptor, NULL, DumpCallback, NULL, true, -1);
}
}
in the cpp side and like:
// Save Dump Path
initNative(getExternalCacheDir().getAbsolutePath());
in the java side.
After that implementing the bool DumpCallback(const google_breakpad::MinidumpDescriptor& descriptor, void* context, bool succeeded) function you will be able to do something before the app crashes.
I have experienced and also found this issue which confirms me, that in this function you can't do java callbacks under ART just under DVM (before android 5 - Lollipop).
My example repo for Flutter Android/iOS: https://github.com/Sunbreak/flutter-breakpad.trial
Android
Build libbreakpad_client.a on Linux (e.g. https://multipass.run/)
$NDK is local path of your Android NDK directory
$CLI_BREAKPAD is local clone of https://github.com/Sunbreak/cli-breakpad.trial
cd $BREAKPAD/src/android
cp -r google_breakpad jni
$NDK/ndk-build
Install libbreakpad_client.a of all architectures
mkdir -p ./android/app/src/main/cmakeLibs
cp -r $BREAKPAD/src/android/obj/local/* ./android/app/src/main/cmakeLibs/
run on macOS/Linux
# Device/emulator connected
$ android_abi=`adb shell getprop ro.product.cpu.abi`
$ flutter run
✓ Built build/app/outputs/flutter-apk/app-debug.apk.
I/flutter_breakpad(31631): JNI_OnLoad
D/flutter_breakpad(31631): Dump path: /data/data/com.example.flutter_breakpad/files/f5258c0e-eff3-433a-7ea47880-c756fc17.dmp
$ adb shell "run-as com.example.flutter_breakpad sh -c 'cat /data/data/com.example.flutter_breakpad/files/f5258c0e-eff3-433a-7ea47880-c756fc17.dmp'" >| libflutter-breakpad.so.dmp
run on Linux (e.g. https://multipass.run/)
$ $CLI_BREAKPAD/breakpad/linux/$(arch)/dump_syms build/app/intermediates/cmake/debug/obj/${android_abi}/libflutter-breakpad.so > libflutter-breakpad.so.sym
$ uuid=`awk 'FNR==1{print \$4}' libflutter-breakpad.so.sym`
$ mkdir -p symbols/libflutter-breakpad.so/$uuid/
$ mv ./libflutter-breakpad.so.sym symbols/libflutter-breakpad.so/$uuid/
$ $CLI_BREAKPAD/breakpad/linux/$(arch)/minidump_stackwalk libflutter-breakpad.so.dmp symbols/ > libflutter-breakpad.so.log
compile ffmpeg with android ndk r5b.
ffmpeg 0.6.1
android ndk r5b
cygwin 1.7
build reference url : http://www.cnblogs.com/scottwong/archive/2010/12/17/1909455.html
but, ffmpeg ./configure result error! (below config.err file)
check_cc
BEGIN /tmp/ffconf.GlDiY1P8.c
1 int main(void){ return 0; }
END /tmp/ffconf.GlDiY1P8.c
/android-ndk-r5b/toolchains/arm-eabi-4.4.0/prebuilt/windows/bin/arm-eabi-gcc -fPIC -DANDROID -c -o /tmp/ffconf.1kQLpGaU.o /tmp/ffconf.GlDiY1P8.c
arm-eabi-gcc.exe: /tmp/ffconf.GlDiY1P8.c: No such file or directory
arm-eabi-gcc.exe: no input files
C compiler test failed.
so, i just try test code.
// test.c code
int main(){
return 0;
}
/android-ndk-r5b/toolchains/arm-eabi-4.4.0/prebuilt/windows/bin/arm-eabi-gcc -fPIC -DANDROID -c -o ./test.o ./test.c
ok!!!! no problem.
but,
cp ./test.c /tmp (copy to /tmp)
/android-ndk-r5b/toolchains/arm-eabi-4.4.0/prebuilt/windows/bin/arm-eabi-gcc -fPIC -DANDROID -c -o ./test.o /tmp/test.c
arm-eabi-gcc.exe: /tmp/test.c: No such file or directory
arm-eabi-gcc.exe: no input files
fail!!!
difference is only file path. /tmp directory exist, and permission is right. /home/test.c is same result.
what's wrong?
I have had a hard time to get it working in Windows, but finally I've managed to do it!
The previous posts were correct - there's a problem with Cygwin paths and Windows paths.
I have tried the solution described in the post above as the very first thing, but it was not working. Finally I've understand the reason: even if you put into your build_android.sh file the Windows path, the config for FFmpeg still contains the wrong path.
So in my case I have changed partially the config file in FFmpeg root directory from:
#set temporary file name
: ${TMPDIR:=$TEMPDIR}
: ${TMPDIR:=$TMP}
: ${TMPDIR:=/tmp}
to this:
# set temporary file name
#: ${TMPDIR:=$TEMPDIR}
#: ${TMPDIR:=$TMP}
: ${TMPDIR:=D:/InstallTools/Android/Cygwin_Root/tmp}
After this, I got it compiling.
You don't set the tmp directory. You can set it in /etc/profile or just in the terminal with export TMPDIR=/your/tmp/directory.
Notice:
1. If you compile with cygwin, the directory must be like D:/tmp. You can't use /cygdrive/d/tmp.
2. You must have the permission of the folder.
I could not get this to work either, I had the exact same problem. However I was able to compile using "android-ndk-r4". I am not sure at the moment what is causing the problem but if I ever get around to figuring it out I'll post that too.
So for now workaround is to use ndk r4.
I managed to build it, using NDK R6, cygwin. Indeed, it does not support /cydrive/ paths, simply use paths like windows; example below:
NDK=e:/AndroidSDK/NDK6
PLATFORM=$NDK/platforms/android-9/arch-arm/
PREBUILT=$NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows
If you have not solved this problem, check the last part of config.log in the ffmpeg directory; it is most likely a path or CC parameter problem.
I have been having the exact same problem with r6. I have tried Lambage's suggestion with r4 but still could not get this to work.
I have been looking into the problem quite a lot and I think I've discovered the reason.
1)configure is calling the android cross compiler which is a windows .exe file.
2)It is calling it through cygwin which uses unix file naming conventions. E.G /cygdrive/c/directory instead of C:\directory
3)It says in the android NDK toolchain documentation that the cross compilers do NOT accept cygwin style filepaths (source: NDK/docs/STANDALONE_TOOLCHAIN.html):
5.1/ Windows support:
The Windows binaries do not depend on Cygwin. The good news is that they
are thus faster, the bad news is that they do not understand the Cygwin
path specification like /cygdrive/c/foo/bar (instead of C:/foo/bar).
I'm still trying to find a way to do this. If i solve it then I'll come back and edit this post...tbc