Develop Reference

Error while creating a new activity in Android Studio

Every time I create a new activity in Android Studio, I get an error like this:
Read access is allowed from event dispatch thread or inside read-action only (see com.intellij.openapi.application.Application.runReadAction())
Details: Current thread: Thread[ApplicationImpl pooled thread 17,4,main] 1345722054;
dispatch thread: false; isDispatchThread(): false
SystemEventQueueThread: Thread[AWT-EventQueue-0 1.3#AI-141.2178183, eap:false,6,main] 2033877427
It doesn't cause any problem though, and the activity is created like it should normally be. So what is the problem?

There is no evidence that this log is related to your application.
it has something to do with android studio (intellij) which you can easily ignore as long as everything is working fine for you.

Android. NDK. How to log calling destructor of global variable?

As we all know android doesn't unload *.so after close application. I had found the solve by adding "exit(0)" at the end, that is solved problem, but I wanna know exactly that all are OK.
The code is work fine as expected after solving the problem:
static int value = 0;
// In android_main
LOGI("value = %d", value); // always print 0, but not 1 after second run of
// application as it was without "exit(0)" at the end
value = 1;
I wanna to test that on class like:
class A {
A() {
LOGI("Constructor");
}
~A() {
LOGI("Destructor");
}
statis A a;
In such way prints only "Constructor".
Maybe because of destructor is calling after when LOGI isn't working more for application that will be closed ?
Question: why LOGI in destructor isn't working? According to first example on top destructor is calling really.

This is not only pointless, but quite possibly counterproductive. If android wants the memory utilized by your process, it will terminate the process to reclaim it; if it doesn't, it won't.
To specifically address your question, killing or exiting a process does not invoke destructors, it merely terminates execution and the kernel bulk-releases all memory and (conventional) resources.
Do not try to second guess the system, as that can frequently result in killing a process only to have android immediately restart it. Further, it can allegedly cause problems with a few Android IPC resources (like the camera) which may not be freed up when the process of a utilizing application unexpectedly dies.

Can't execute JavaVM->DetachCurrentThread(): "attempting to detach while still running code"

I have an Android app that uses NDK - a regular Android Java app with regular UI and C++ core. There are places in the core where I need to call Java methods, which means I need a JNIEnv* for that thread, which in turn means that I need to call JavaVM->AttachCurrentThread() to get the valid env.
Previously, was just doing AttachCurrentThread and didn't bother to detach at all. It worked fine in Dalvik, but ART aborts the application as soon as a thread that has called AttachCurrentThread exits without calling DetachCurrentThread. So I've read the JNI reference, and indeed it says that I must call DetachCurrentThread. But when I do that, ART aborts the app with the following message:
attempting to detach while still running code
What's the problem here, and how to call DetachCurrentThread properly?

Dalvik will also abort if the thread exits without detaching. This is implemented through a pthread key -- see threadExitCheck() in Thread.cpp.
A thread may not detach unless its call stack is empty. The reasoning behind this is to ensure that any resources like monitor locks (i.e. synchronized statements) are properly released as the stack unwinds.
The second and subsequent attach calls are, as defined by the spec, low-cost no-ops. There's no reference counting, so detach always detaches, no matter how many attaches have happened. One solution is to add your own reference-counted wrapper.
Another approach is to attach and detach every time. This is used by the app framework on certain callbacks. This wasn't so much a deliberate choice as a side-effect of wrapping Java sources around code developed primarily in C++, and trying to shoe-horn the functionality in. If you look at SurfaceTexture.cpp, particularly JNISurfaceTextureContext::onFrameAvailable(), you can see that when SurfaceTexture needs to invoke a Java-language callback function, it will attach the thread, invoke the callback, and then if the thread was just attached it will immediately detach it. The "needsDetach" flag is set by calling GetEnv to see if the thread was previously attached.
This isn't a great thing performance-wise, as each attach needs to allocate a Thread object and do some internal VM housekeeping, but it does yield the correct behavior.

I'll try a direct and practical approach (with sample code, without use of classes) answering this question for the occasional developer that came up with this error in android, in cases where they had it working and after a OS or framework update (Qt?) it started to give problems with that error and message.
JNIEXPORT void Java_com_package_class_function(JNIEnv* env.... {
JavaVM* jvm;
env->GetJavaVM(&jvm);
JNIEnv* myNewEnv; // as the code to run might be in a different thread (connections to signals for example) we will have a 'new one'
JavaVMAttachArgs jvmArgs;
jvmArgs.version = JNI_VERSION_1_6;
int attachedHere = 0; // know if detaching at the end is necessary
jint res = jvm->GetEnv((void**)&myNewEnv, JNI_VERSION_1_6); // checks if current env needs attaching or it is already attached
if (JNI_EDETACHED == res) {
// Supported but not attached yet, needs to call AttachCurrentThread
res = jvm->AttachCurrentThread(reinterpret_cast<JNIEnv **>(&myNewEnv), &jvmArgs);
if (JNI_OK == res) {
attachedHere = 1;
} else {
// Failed to attach, cancel
return;
}
} else if (JNI_OK == res) {
// Current thread already attached, do not attach 'again' (just to save the attachedHere flag)
// We make sure to keep attachedHere = 0
} else {
// JNI_EVERSION, specified version is not supported cancel this..
return;
}
// Execute code using myNewEnv
// ...
if (attachedHere) { // Key check
jvm->DetachCurrentThread(); // Done only when attachment was done here
}
}
Everything made sense after seeing the The Invocation API docs for GetEnv:
RETURNS:
If the current thread is not attached to the VM, sets *env to NULL, and returns JNI_EDETACHED. If the specified version is not supported, sets *env to NULL, and returns JNI_EVERSION. Otherwise, sets *env to the appropriate interface, and returns JNI_OK.
Credits to:
- This question Getting error "attempting to detach while still running code" when calling JavaVm->DetachCurrentThread that in its example made it clear that it was necessary to double check every time (even though before calling detach it doesn't do it).
- #Michael that in this question comments he notes it clearly about not calling detach.
- What #fadden said: "There's no reference counting, so detach always detaches, no matter how many attaches have happened."

Qt/C++: interrupt QProcess arbitrarily with button (simulate ^c)

So I need to make a Qt Application (with GUI) that executes the "adb logcat" command (it's a log that keeps being generated until ^c is pressed).
I need a GUI button to make the process stop and pass the output to a Text Browser.
This is the code I use to get the QProcess output:
QProcess process;
process.start("adb logcat");
process.waitForFinished(-1);
QByteArray logcatOut = process.readAllStandardOutput();
ui->devicesOutput->setText(logcatOut);
Thank you

process.waitForFinished(-1);
would prevent your program of being executed further, till the process "adb" has finished.
So your GUI will be frozen.
You should define QProcess process as a class variable. Use QProcess
*process; instead of creating it on stack. (Best practice for all QObject derivates)
Declare a slot which handles clicked-signal of your button.
call process->terminate() in the slot.

use QProcess::terminate to stop running app

Android Application launch process

I am searching for some information about how are apps launch on android. I want ot found infromation what make zygote and about fork() . Do you know some usefull web-sites or books?

I have written a two part series to explain Android Application launch process on my blog -
http://multi-core-dump.blogspot.com/2010/04/android-application-launch.html
http://multi-core-dump.blogspot.com/2010/04/android-application-launch-part-2.html
I hope you will find it useful.

There is a nice explanation in this presentation. It's written partially in Korean, but the most part of information in English.

Here is an concise(the process is very complex so a concise one still won't be a short one) yet precise answer based on AOSP 9.0.0.
Every Android Java process is forked from Zygote, so first is how Zygote starts.
init process is the first process in linux, it start the executable "app_process", whose internal is :
(entry point of app_process)int main
->void AndroidRuntime::start
startVm //start Java VM
startReg //register common native functions
//call java method ZygoteInit.main from native code
env->CallStaticVoidMethod
Then here is the most important java method: ZygoteInit.main, we get here from the above native code "env->CallStaticVoidMethod ".
This is also the first method in the call stack when you set a break point in main Activity's onCreate and start debuging your application and break there. But in fact your application never get to the beginning of ZygoteInit.main, it is executed from the beginning only in app_process(or say Zygote).
//Java code
->ZygoteInit.main
//Android application never get here(the beginning)
//start system server process which contains AMS/WMS,etc
forkSystemServer
//for Zygote, runSelectLoop never return
//for Android application, runSelectLoop returns a Runnable
//whose run() method will just execute ActivityThread.main
//which is considered as the real main entry of Android application
//since it contains the message loop
caller = zygoteServer.runSelectLoop
->zygoteServer.runSelectLoop
//this is the main loop of Zygote who is a
//server that receive process-creating requests
//from client processes and fork them
loop forever
//Zygote wait here for other process's requests to start new Java process
Os.poll(pollFds, -1);
//after wake up upon requests arrive, process the request
final Runnable command = connection.processOneCommand(this);
->ZygoteConnection.processOneCommand
read and parse process-start request command from client process
//the native linux fork() is executed in this methdod
//after it returns, we can decide which process we are in
//from pid's value just like the native fork()
pid = Zygote.forkAndSpecialize
//if in child
return handleChildProc
->ZygoteConnection.handleChildProc
return ZygoteInit.zygoteInit
->ZygoteInit.zygoteInit
RuntimeInit.commonInit();
ZygoteInit.nativeZygoteInit();//JNI method
//native code
->AppRuntime::onZygoteInit()
sp<ProcessState> proc = ProcessState::self();
//starting thread pool which contains binder threads
proc->startThreadPool();
return RuntimeInit.applicationInit
->RuntimeInit.applicationInit
return findStaticMain
->RuntimeInit.findStaticMain
//MethodAndArgsCaller is a Runnable,
//whose run() is constructed so that
//it just call ActivityThread.main()
//it is ActivityThread since there is a string parameter
//whose content is "android.app.ActivityThread" from the client process's request
return new MethodAndArgsCaller
//if in parent process i.e. Zygote
return null
//if in forked child process
return command;
//if in parent process i.e. Zygote
continue to run the loop
//Zygote never get here
//for Android application, now caller contains a MethodAndArgsCaller which is a Runnable
//whose run() calls ActivityThread.main and never return
//since ActivityThread.main runs the main message loop
caller.run();
When you start an Activity, finally you get into in Activity Manager Service(AMS, which is in system server process). If the process for that Activity is not created yet, AMS will send process-start request request to Zygote server (in the zygote process described above,started by init process), the process is like:
//in AMS (system server process)
final String entryPoint = "android.app.ActivityThread";
return startProcessLocked(....,entryPoint, ....);
->startProcessLocked
->Process.start
->ZygoteProcess.start
->ZygoteProcess.startViaZygote
->ZygoteProcess.zygoteSendArgsAndGetResult
//send the request to Zygote server through sockets
//note that "android.app.ActivityThread" is send to Zygote server as a parameter
At this time, the above listed Zygote code will wake up from
Os.poll(pollFds, -1);
and fork the child process, and after this, the parent process i.e. Zygote will again execute poll waiting for the next request, and the forked child process will return from runSelectLoop and execute ActivityThread.main as described in the above code listing.
So the exact entry point of the new process will be after the native fork() deep down in Zygote.forkAndSpecialize, in a native function called ForkAndSpecializeCommon to be exactly, then all the way up through a return route up to
caller = zygoteServer.runSelectLoop
in ZygoteInit.main. So although the call stack of an Android application start at ZygoteInit.main, the code executed in ZygoteInit.main begins after the call to runSelectLoop instead of the beginning of ZygoteInit.main.
About Activity: in fact Activity has nothing to do with entry point or start up process. An Activity is started when AMS send an Activity-start request to a process at any time. So Activity start process always begin in the main message loop when the start request is received, it is driven by message from AMS and is fully decoupled from the application start process.