2012-04-19 2 views
4

Я пишу приложение Java, которое разговаривает с приложением C++ с использованием именованных каналов. Когда приложение C++ умирает, Java получает SIGPIPE и приложение Java умирает.Обработка сигналов unix в Android

На C/C++ Я знаю, как поймать этот сигнал и игнорировать его. Возможно ли сделать что-то подобное на Android/Java?

+1

Может быть, это хорошо, чтобы не бороться с правилами игра: если ваше приложение java привязано к C++, и больше нет связи, просто спустите приложение Java и перезапустите его. Эта ссылка может быть полезна: http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-the-sigkill-signal-in-java - как установить крюк отключения. –

+0

Это ** возможно ** см., Например, http://stackoverflow.com/questions/1083154/how-can-i-catch-sigsegv-segmentation-fault-and-get-a-stack-trace-under-jni -on –

+0

@ChrisStratton кажется интересным. Благодаря! – elcuco

ответ

1

Кажется, это невозможно. Лучшее решение, доступное бы добавить закрыть крючок и «изящно» перезапустить приложение, как описано здесь:

EDIT:

мне это было нужно, потому что (тогда) я имел JNI код, на котором Я открыл FD и r/w. FD был открыт для именованного сокета (Unix-канал), и когда удаленная сторона канала (в моем случае демон или Android C/service) закрывает соединение (или умирает), ваша сторона получит сигнал. Это не всегда приятно. ИМХО лучше всего справиться с этим, должен использовать обработчик сигналов из старого старого кода с открытым кодом и просто проглатывать его (в противном случае вы должны уведомить Java-часть вашего приложения).

http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-the-sigkill-signal-in-java
+1

В этом ответе приводится объяснение на основе jvm, которое не обязательно применимо к Android, так как в то время как Android использует код, скомпилированный и переведенный из формы Java, на самом деле он не запускает виртуальную машину Java, а скорее его собственный Dalvik (или совсем недавно Android Runtime), который имеет несколько другое поведение. Кроме того, вполне вероятно, что - по крайней мере, с NDK - можно заменить любой обработчик сигнала в своем собственном процессе DVM. –

+0

Я не сказал, что это не сработает, скорее, что ссылка не полностью применима и что, похоже, существуют способы ее работы. –

Смежные вопросы