Android reboot command - Who calls reboot_main()? - android

I am looking at the source for the android shell reboot command.
int reboot_main(int argc, char *argv[])
What I am not clear about is if this is a standalone binary, who calls reboot_main() ?
In a standard glibc linked binary, I was expecting to find a "main()" as the entry point for the program.
What am I missing here, could someone help me understand what is going on ?
Thanks,
vj

They are all compiled into one overall executable, with main in https://android.googlesource.com/platform/system/core.git/+/android-4.2.2_r1/toolbox/toolbox.c
Then, based on the actual program name invoked (usually argv[0]) it calls the appropriate method.
The commands are part of the build via the
#define TOOL(name) int name##_main(int, char**);
macro in toolbox.c which is used in the Android.mk file to generate tools.h.

Related

Undefined references when cross-compiling code to run on x86_64-linux-android: gethostid, assert_fail, errno_location not found

I am building some code that is mainly FORTRAN (eek) but also has some C code. I am using NDK revision 21 (android-ndk-r21d). All is well, until the main program link, when I get undefined references to gethostid(), assert_fail(), and errno_location() from some of the C code. It seems these should be in the NDK libc.a but do not see them there. I could write dummy stubs (something that returns 0) as fill-ins for these but this seems not to be an optimal path forward. I would have gone straight to an Android NDK user group but didn't see one offhand. If someone knows of one that would be great.
thanks,
Steve
You can try to grep NDK package:
~/Projects/Android/AS/Sdk/ndk/21.3.6528147$ grep -irn -e gethostid -e assert_fail -e errno_location --include=*.h
toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/include/sanitizer/netbsd_syscall_hooks.h:744:#define __sanitizer_syscall_pre_compat_43_ogethostid() \
toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/include/sanitizer/netbsd_syscall_hooks.h:745: __sanitizer_syscall_pre_impl_compat_43_ogethostid()
toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/include/sanitizer/netbsd_syscall_hooks.h:746:#define __sanitizer_syscall_post_compat_43_ogethostid(res) \
toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/include/sanitizer/netbsd_syscall_hooks.h:747: __sanitizer_syscall_post_impl_compat_43_ogethostid(res)
toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/include/sanitizer/netbsd_syscall_hooks.h:3250:void __sanitizer_syscall_pre_impl_compat_43_ogethostid(void);
toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/include/sanitizer/netbsd_syscall_hooks.h:3251:void __sanitizer_syscall_post_impl_compat_43_ogethostid(long long res);
toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/include/__clang_cuda_runtime_wrapper.h:348:// provide device-side __assert_fail()
toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/include/__clang_cuda_runtime_wrapper.h:349:__device__ static inline void __assert_fail(const char *__message,
toolchains/renderscript/prebuilt/linux-x86_64/clang-include/__clang_cuda_runtime_wrapper.h:250:// provide device-side __assert_fail()
toolchains/renderscript/prebuilt/linux-x86_64/clang-include/__clang_cuda_runtime_wrapper.h:251:__device__ static inline void __assert_fail(const char *__message,
It seems that only __assert_fail presents in __clang_cuda_runtime_wrapper.h header, but file name tells us that it was not expected for general use.

armeabi-v7a compiling error for cpp file

I am using getline function and compiling using ndk but i am getting error :
'getline' was not declared in this scope
is this error due to limitations of armeabi-v7a or due to glib?How can it be resolved for the same function.
I have already #define _GNU_SOURCE before <stdio.h>
In general, when you encounter such an error, you go to your NDK directory and user either Midnight Commander (Linux) or Far Manager (Windows, Linux+Wine) to search the files (file mask: *.h) for your function, getline in this case. You will get a screenful of search results, and it's up to you to #include the right file.
Once in a while your function will not be found; in this case you search the 'net for a place where you can borrow the source.
Sometimes the function in the code being ported has just no meaning, e.g. if the function reads a line from stdin but the program going to invoke it is not a command-line utility, there is a problem.
Most likely, the source that you port #define-s switches for Linux, Mac (Darwin) and Windows, you have to choose the right configuration to derive the Android configuration from (and probably the Mac one will be the best).

Makefile(s) debug: which file/line calls to a command?

I'm facing a bug in a makefile build system (Android built under Linux) - some files are removed by an 'rm' command, and I can see that command in the build log.
How can I find the exact line in the makefiles which calls the 'rm' ? Is there any automated method?
For GNU Make you can do the following trick:
__shell := $(SHELL)
SHELL = \
$(warning making '$#'$(if $^, from '$^')$(if $?, because of '$?'))$(__shell)
SHELL variable is expanded each time when Make invokes a sub-shell to execute a recipe. In these lines it is replaced so that on each expansion it will print a target, its prerequisites and prerequisites that are newer than the target. Also each debug message is prepended with the file and line number of the rule being executed.
The same technique is used in GMD to set breakpoints to certain targets.
Assuming your make is a Gnu make, you can also pass some debugging options, like --debug=b (basic debugging messages, very often enough) or --debug=all which is the same as -d
Some files may be removed because they are intermediate. Read also about secondary files and precious files in make
You may try make -d -w and then grep your file from huge amount of output lines.

Retrieve Logcat data through native (C) code

I was wondering if there is any way to access the logcat logging data from native code ?
Also if someone knows what kind of shell can be accessed on the native linux system directly on the device itself (so NOT by starting a shell through adb on a client pc !!!) ?
Thanks in advance
You can either read the raw data fom /dev/log/main or you can run the built-in shell command logcat and pipe the result to a file descriptor as usual. The logcat command is usually preferably because then the printout is easier to filter and format.
As for the built-in shell, it is called toolbox and the source can be found in the Android open source project. The shell is rather similar to bash. Toolbox contains lots more functionality than just a shell. It is very similar to Busybox, but released under another license.
You can set it up using a log tag in your source file and then include the library as so:
#define LOG_TAG "some.unique.identifier" //I usually use the class name
#include <utils/Log.h>
Then in the Android.mk file you will need to add the liblog library dependency to your LOCAL_SHARED_LIBRARIES.
LOCAL_SHARED_LIBRARIES += liblog
Also, take note that logcat looks for the LOG_TAG definition to include as part of the tagging so it makes searching for your logs easier. Then you can log as such:
int my_int = 0;
ALOGI("some logs.... print my int: %d", my_int);
ALOGI is for info, you can also use ALOGE, ALOGD, ALOGV and ALOGW for error, debug, verbose and warning logging, respectively.
ALOG* is analogous to printf. I interchange them at times if I need to debug on different platforms, say Linux.

Pure C++ program compiled for Android

I want to compile this program for Android and see it run on my phone:
#include "Hello World.h"
using namespace codewerks;
//=============================================
// Main Loop
//=============================================
int main(int argc, char* argv[])
{
Print(std::string("Hello World!"));
}
Where do I start? Can I compile this with GCC? The NDK seems focused on Java. Thank you.
This is now possible with the latest NDK. You will need an emulator or phone running Android 2.3 to try it, but the NativeActivity documentation has a complete example.
Unfortunately it is somewhat more complicated than a simple "hello world" example, and "main" is spelled "android_main". You still need to worry about your application life cycle as you do in Java, and the only real way to draw to the screen is to use OpenGL ES. It seems to be designed for writing games for Android.
Build as executable. (BUILD_EXECUTABLE)
Copy the executable to sdcard. (adb push)
Go to android shell. (adb shell)
Change the permission of the executable. (chmod 777)
Run the executable. (./out)
You will see the printed result on the console. (happy?)

Categories

Resources