精华内容
下载资源
问答
  • ps -l:只查看自己bash的进程 ps aux:可以查看所有系统运行的进程。 -a:显示与终端有关的所有进程 -u:有效使用者相关的进程 -x:通常与a这个参数一起使用,列出较完整的信息 -l:较详细的将PID的信息列出 ...
    • ps -l:只查看自己bash的进程
    • ps aux:可以查看所有系统运行的进程。
      -a:不显示与终端有关的所有进程
      -u:有效使用者相关的进程
      -x:通常与a这个参数一起使用,可列出较完整的信息
      -l:较详细的将PID的信息列出
    • kill -9 PID:强制删除一个不正常的任务
    展开全文
  • 信号系统中信号的默认行为有4种用户对信号选的自定义操作有3种选择`捕捉`信号选择`忽略`信号选择信号`默认`行为用户不可以修改其行为的信号常见的信号信号相关的函数接口`kill` 发送信号`pause` 阻塞等待一个信号...

    信号是linux系统中进程间通信的一种方式, 它是一种异步的通信机制, 用来告诉某个进程, 某种事件已经发生。

    系统中信号的默认行为有4种

    1. 终止, 进程停止运行
    2. 忽略, 进程对信号不做任何回应
    3. 停止, 进程暂停运行, 并未停止, 还可以恢复
    4. 继续, 进程从停止的状态恢复运行

    用户对信号可以采取自定义操作。

    用户对信号可选的自定义操作有3种

    1. 捕捉, 监测到信号时, 对信号行为重定义, 执行用户自定义的函数
    2. 忽略, 检测到信号时, 无论信号的系统默认行为是什么, 都主动忽略
    3. 默认, 检测到信号时, 执行系统默认的信号行为
    自定义捕捉信号
    /**
     * Description: 捕捉Ctrl + C信号
     * File: signal.c |Time: 2021-05-30 17:31
     */
    
    #include <stdio.h>
    #include <signal.h>
    #include <unistd.h>
    
    void sig_handler(int signum)
    {
    	printf("signal [%d] catched.\n", signum);
        printf("Ctrl + c pressed.\n");
        // 发送终止信号终止进程
        kill(getpid(), SIGKILL);
        return ;
    }
    
    int main(int argc, const char *argv[])
    {
    	// 注册一个信号处理程序, 异步信号到来时自动调用sig_handler函数
        signal(SIGINT, sig_handler);
    
        while(1)
        {
            sleep(1);
        }
        return 0;
    }
    
    自定义忽略信号
    /**
     * Description: 设置信号发生时, 忽略信号的行为
     * File: signal.c |Time: 2021-05-30 17:31
     */
    
    #include <stdio.h>
    #include <signal.h>
    #include <unistd.h>
    
    int main(int argc, const char *argv[])
    {
        // 选择忽略信号
        signal(SIGINT, SIG_IGN);
    
        sleep(5);
        kill(SIGKILL, getpid());
        return 0;
    }
    
    自定义信号默认行为
    /**
     * Description: 设置信号发生时采用系统默认行为
     * File: signal.c |Time: 2021-05-30 17:31
     */
    
    #include <stdio.h>
    #include <signal.h>
    #include <unistd.h>
    
    int main(int argc, const char *argv[])
    {
        // 选择默认的行为
        signal(SIGINT, SIG_DFL);
    
        while(1)
        {
            sleep(1);
        }
        return 0;
    }
    

    不可以自定义其行为的信号

    信号常量 信号值 默认行为 说明
    SIGKILL 9 终止 不可被忽略
    SIGSTOP 19 暂停 不可被忽略

    常见的信号

    信号常量 信号值 默认行为 说明
    SIGHUP 1 终止 在用户终端关闭时产生, 通常是发给和该终端相关联的所有进程
    SIGINT 2 终止 在用户输入INTR字符(Ctrl + C)时产生, 内核会发送这个信号到当前终端的所有前台进程
    SIGQUIT 3 终止 与SIGINT类似, 但是由QUIT字符(Ctrl + )产生
    SIGILL 4 终止 该信号在一个进程企图执行一条非法指令时产生
    SIGSEGV 11 终止 该信号在非法访问内存时产生, 如野指针, 缓冲区溢出
    SIGPIPE 13 终止 当进程往一个没有读端的管道中写入时产生, 代表“管道破裂”
    SIGKILL 9 终止 结束进程, 并且不能被捕捉和忽略
    SIGCHLD 17 忽略 子进程退出向父进程发送此信号
    SIGSTOP 19 暂停进程 暂停进程, 并且不能被捕捉和忽略
    SIGTSTP 20 暂停进程 暂停进程, 用户输入SUSP字符(Ctrl + Z)时产生
    SIGCONT 18 继续运行 该信号让进程进入运行态
    SIGALRM 14 终止 该信号用于通知进程定时器时间已到
    SIGUSR1 10 终止 该信号保留给用户进程使用, 系统不会自动产生
    SIGUSR2 13 终止 该信号保留给用户进程使用, 系统不会自动产生

    信号相关的函数接口

    kill 发送信号
    /**
     * Description: 发送一个信号
     * File: signal.c |Time: 2021-05-30 17:31
     */
    
    #include <stdio.h>
    #include <signal.h>
    #include <unistd.h>
    
    int main(int argc, const char *argv[])
    {
        pid_t pid = getpid();
        // 3秒后发送一个信号杀掉自己
        sleep(3);
        kill(pid, SIGKILL);
    
        return 0;
    }
    
    pause 阻塞等待一个信号到来
    1. pause会使一个进程进入无限期休眠状态, 直到一个信号来将它唤醒
    2. 唤醒pause的信号必须是默认终止进程类型的信号, SIGCHLD 不好使
    3. pause 函数没有成功返回, 只会返回 -1
    /**
     * Description: pause函数接口的使用
     * File: signal.c |Time: 2021-05-30 17:31
     */
    
    #include <stdio.h>
    #include <unistd.h>
    #include <stdlib.h>
    #include <signal.h>
    
    void sig_handler(int signum){}
    
    int main(int argc, const char *argv[])
    {
        int i = 0;
    
        // 过5秒中发送时钟信号
        // 修改时钟信号默认行为, 不执行任何操作
        alarm(5);
        signal(SIGALRM, sig_handler);
    
        for (i = 0; i < 5; i++)
        {
            // pause会无限期挂起当前进程,直到有信号来唤醒
            // pause只会返回-1
            // 这里模拟, 当程序完成几个任务后进入无限期休眠,
            // 后来时钟信号到来, 唤醒pause, 程序继续运行
            if (i == 2 && -1 == pause())
            {
                perror("pause");
                continue;
            }
    
            printf("runing something %d ... \n", i);
            sleep(1);
        }
    
        return 0;
    }
    
    raise 给自己发送一个信号
    /**
     * Description: raise的使用
     * File: signal.c |Time: 2021-05-30 17:31
     */
    
    #include <stdio.h>
    #include <unistd.h>
    #include <signal.h>
    
    
    int main(int argc, const char *argv[])
    {
        // 5 秒后会给自己发送一个SIGKILL信号结束自己
        while(1){
            sleep(5);
            raise(SIGKILL);
        }
    
        return 0;
    }
    
    alarm 定时给自己发送一个信号
    /**
     * Description: alarm的使用
     * File: signal.c |Time: 2021-05-30 17:31
     */
    
    #include <stdio.h>
    #include <unistd.h>
    
    
    int main(int argc, const char *argv[])
    {
        // 5 秒后会给自己发送一个SIGALRM信号结束自己
        alarm(5);
        while(1){
            sleep(1);
        }
    
        return 0;
    }
    
    展开全文
  • 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...

    序言

    最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证service不被kill,这可真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的Service不被杀死呢?

    其实除了常规的手段,我们可以参考一下微信和360,设置-程序-正在运行,可以看到微信是同时开启了两个进程和服务:

    【有兴趣可以研究一下 守护进程 AIDL


    我猜想它应该是相互监听,如果有一方被kill掉,另一个捕获到立即启动,以达到service永远都在运行的状态,貌似360也是这个原理,具体是不是这个样子,还有待参考,目前我还没有参透它们是如何实现的,先简单说一下我自己的防控措施吧,首先介绍一下Service概念,记性不好,重复造一下车轮,高手可以直接看最后。



    Service简介

    Service是在一段不定的时间运行在后台,不和用户交互应用组件。每个Service必须在manifest中 通过<service>来声明。可以通过contect.startservice和contect.bindserverice来启动。和其他的应用组件一样,运行在进程的主线程中。这就是说如果service需要很多耗时或者阻塞的操作,需要在其子线程中实现(或者用系统提供的IntentService,它继承了Service,它处理数据是用自身新开的线程)。【当然你也可以在新的线程中startService,这样Service就不是在MainThread了


    本地服务 Local Service 用于应用程序内部

    它可以启动并运行,直至有人停止了它或它自己停止。在这种方式下,它以调用Context.startService()启动,而以调用Context.stopService()结束。它可以调用Service.stopSelf() 或 Service.stopSelfResult()来自己停止。不论调用了多少次startService()方法,你只需要调用一次stopService()来停止服务。

    【用于实现应用程序自己的一些耗时任务,比如查询升级信息,并不占用应用程序比如Activity所属线程,而是单开线程后台执行,这样用户体验比较好】


    远程服务 Remote Service 用于android系统内部的应用程序之间

    它可以通过自己定义并暴露出来的接口进行程序操作。客户端建立一个到服务对象的连接,并通过那个连接来调用服务。连接以调用Context.bindService()方法建立,以调用 Context.unbindService()关闭。多个客户端可以绑定至同一个服务。如果服务此时还没有加载,bindService()会先加载它。

    【可被其他应用程序复用,比如天气预报服务,其他应用程序不需要再写这样的服务,调用已有的即可】


    1,Service的生命周期



    2,Service运行方式

    以startService()启动服务,系统将通过传入的Intent在底层搜索相关符合Intent里面信息的service。如果服务没有启动则先运行onCreate,然后运行onStartCommand (可在里面处理启动时传过来的Intent和其他参数),直到明显调用stopService或者stopSelf才将停止Service。无论运行startService多少次,只要调用一次stopService或者stopSelf,Service都会停止。使用stopSelf(int)方法可以保证在处理好intent后再停止。onStartCommand ,在2.0后被引入用于service的启动函数,2.0之前为public void onStart(Intent intent, int startId) 。

    以bindService()方法启用服务,调用者与服务绑定在了一起,调用者一旦退出,服务也就终止。onBind()只有采用Context.bindService()方法启动服务时才会回调该方法。该方法在调用者与服务绑定时被调用,当调用者与服务已经绑定,多次调用Context.bindService()方法并不会导致该方法被多次调用。采用Context.bindService()方法启动服务时只能调用onUnbind()方法解除调用者与服务解除,服务结束时会调用onDestroy()方法。


    3,拥有service的进程具有较高的优先级

    官方文档告诉我们,Android系统会尽量保持拥有service的进程运行,只要在该service已经被启动(start)或者客户端连接(bindService)到它。当内存不足时,需要保持,拥有service的进程具有较高的优先级。

    1. 如果service正在调用onCreate,onStartCommand或者onDestory方法,那么用于当前service的进程则变为前台进程以避免被killed。
    2. 如果当前service已经被启动(start),拥有它的进程则比那些用户可见的进程优先级低一些,但是比那些不可见的进程更重要,这就意味着service一般不会被killed.
    3. 如果客户端已经连接到service (bindService),那么拥有Service的进程则拥有最高的优先级,可以认为service是可见的。
    4. 如果service可以使用startForeground(int, Notification)方法来将service设置为前台状态,那么系统就认为是对用户可见的,并不会在内存不足时killed。
    5. 如果有其他的应用组件作为Service,Activity等运行在相同的进程中,那么将会增加该进程的重要性。


    保证service不被杀掉


    onStartCommand方法,返回START_STICKY


    StartCommond几个常量参数简介:

    1、START_STICKY

    在运行onStartCommand后service进程被kill后,那将保留在开始状态,但是不保留那些传入的intent。不久后service就会再次尝试重新创建,因为保留在开始状态,在创建     service后将保证调用onstartCommand。如果没有传递任何开始命令给service,那将获取到null的intent。

    2、START_NOT_STICKY

    在运行onStartCommand后service进程被kill后,并且没有新的intent传递给它。Service将移出开始状态,并且直到新的明显的方法(startService)调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动,也就是期间onstartCommand不会接收到任何null的intent。

    3、START_REDELIVER_INTENT

    在运行onStartCommand后service进程被kill后,系统将会再次启动service,并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent,那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。

    1. @Override  
    2. public int onStartCommand(Intent intent, int flags, int startId) {  
    3.     flags = START_STICKY;  
    4.     return super.onStartCommand(intent, flags, startId);  
    5. }  

    【结论】 手动返回START_STICKY,亲测当service因内存不足被kill,当内存又有的时候,service又被重新创建,比较不错,但是不能保证任何情况下都被重建,比如进程被干掉了....



    提升service优先级


    在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = "1000"这个属性设置最高优先级,1000是最高值,如果数字越小则优先级越低,同时适用于广播。

    1. <service  
    2.     android:name="com.dbjtech.acbxt.waiqin.UploadService"  
    3.     android:enabled="true" >  
    4.     <intent-filter android:priority="1000" >  
    5.         <action android:name="com.dbjtech.myservice" />  
    6.     </intent-filter>  
    7. </service>  

    【结论】目前看来,priority这个属性貌似只适用于broadcast,对于Service来说可能无效


    提升service进程优先级


    Android中的进程是托管的,当系统进程空间紧张的时候,会依照优先级自动进行进程的回收。Android将进程分为6个等级,它们按优先级顺序由高到低依次是:

       1.前台进程( FOREGROUND_APP)
       2.可视进程(VISIBLE_APP )
       3. 次要服务进程(SECONDARY_SERVER )
       4.后台进程 (HIDDEN_APP)
       5.内容供应节点(CONTENT_PROVIDER)
       6.空进程(EMPTY_APP)

    当service运行在低内存的环境时,将会kill掉一些存在的进程。因此进程的优先级将会很重要,可以使用startForeground将service放到前台状态。这样在低内存时被kill的几率会低一些。


    在onStartCommand方法内添加如下代码:

    1.  Notification notification = new Notification(R.drawable.ic_launcher,  
    2.  getString(R.string.app_name), System.currentTimeMillis());  
    3.   
    4.  PendingIntent pendingintent = PendingIntent.getActivity(this0,  
    5.  new Intent(this, AppMain.class), 0);  
    6.  notification.setLatestEventInfo(this"uploadservice""请保持程序在后台运行",  
    7.  pendingintent);  
    8. <span style="color:#ff0000;"> startForeground(0x111, notification);</span>  

    注意在onDestroy里还需要stopForeground(true),运行时在下拉列表会看到自己的APP在:



    【结论】如果在极度极度低内存的压力下,该service还是会被kill掉,并且不一定会restart



    onDestroy方法里重启service


    service +broadcast  方式,就是当service走ondestory的时候,发送一个自定义的广播,当收到广播的时候,重新启动service;

    1. <receiver android:name="com.dbjtech.acbxt.waiqin.BootReceiver" >  
    2.     <intent-filter>  
    3.         <action android:name="android.intent.action.BOOT_COMPLETED" />  
    4.         <action android:name="android.intent.action.USER_PRESENT" />  
    5.         <action android:name="com.dbjtech.waiqin.destroy" />//这个就是自定义的action  
    6.     </intent-filter>  
    7. </receiver>  
    在onDestroy时:
    1. @Override  
    2. public void onDestroy() {  
    3.     stopForeground(true);  
    4.     Intent intent = new Intent("com.dbjtech.waiqin.destroy");  
    5.     sendBroadcast(intent);  
    6.     super.onDestroy();  
    7. }  
    在BootReceiver里
    1. public class BootReceiver extends BroadcastReceiver {  
    2.   
    3.     @Override  
    4.     public void onReceive(Context context, Intent intent) {  
    5.         if (intent.getAction().equals("com.dbjtech.waiqin.destroy")) {  
    6.             //TODO  
    7.             //在这里写重新启动service的相关操作  
    8.                 startUploadService(context);  
    9.         }  
    10.   
    11.     }  
    12.   
    13. }  

    也可以直接在onDestroy()里startService

    1. @Override  
    2. public void onDestroy() {  
    3.   
    4.      Intent sevice = new Intent(this, MainService.class);  
    5.      this.startService(sevice);  
    6.   
    7.     super.onDestroy();  
    8. }  

    【结论】当使用类似口口管家等第三方应用或是在setting里-应用-强制停止时,APP进程可能就直接被干掉了,onDestroy方法都进不来,所以还是无法保证~.~



    Application加上Persistent属性


    看Android的文档知道,当进程长期不活动,或系统需要资源时,会自动清理门户,杀死一些Service,和不可见的Activity等所在的进程。但是如果某个进程不想被杀死(如数据缓存进程,或状态监控进程,或远程服务进程),可以这么做:

    1. <application  
    2.     android:name="com.test.Application"  
    3.     android:allowBackup="true"  
    4.     android:icon="@drawable/ic_launcher"  
    5.     android:label="@string/app_name"  
    6.    <span style="color:#ff0000;"> android:persistent="true"</span>  
    7.     android:theme="@style/AppTheme" >  
    8. </application>  


    【结论】据说这个属性不能乱设置,不过设置后,的确发现优先级提高不少,或许是相当于系统级的进程,但是还是无法保证存活



    监听系统广播判断Service状态


    通过系统的一些广播,比如:手机重启、界面唤醒、应用状态改变等等监听并捕获到,然后判断我们的Service是否还存活,别忘记加权限啊。

    1. <receiver android:name="com.dbjtech.acbxt.waiqin.BootReceiver" >  
    2.     <intent-filter>  
    3.         <action android:name="android.intent.action.BOOT_COMPLETED" />  
    4.         <action android:name="android.intent.action.USER_PRESENT" />  
    5.         <action android:name="android.intent.action.PACKAGE_RESTARTED" />  
    6.         <action android:name="com.dbjtech.waiqin.destroy" />  
    7.     </intent-filter>  
    8. </receiver>  
    BroadcastReceiver中:
    1. @Override  
    2. public void onReceive(Context context, Intent intent) {  
    3.     if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) {  
    4.         System.out.println("手机开机了....");  
    5.         startUploadService(context);  
    6.     }  
    7.     if (Intent.ACTION_USER_PRESENT.equals(intent.getAction())) {  
    8.             startUploadService(context);  
    9.     }  
    10. }  

    【结论】这也能算是一种措施,不过感觉监听多了会导致Service很混乱,带来诸多不便


    将APK安装到/system/app,变身系统级应用

    这个办法不推荐使用,因为如果你的APP如果是给用户使用的,那就不合适了,我是为了给测试的妹子来用,这个APP的目的也是很简单,打开后开启Service并且能保证一直在后台驻留,开机自启动。但是昨天发现如果她的HuaWei手机长时间关闭, 再重新打开时,我们应用的Service不会自启动,貌似广播收不到了~一怒之下,打算搞成系统应用。

    前提:
    ROOT过的手机
    1,把代码编写好后,打包导出apk,copy到手机SD卡根目录下。
    2,手机连接eclipse,cmd: adb shell
    3,切换root模式,输入:su     (如果root过就不会有错误)
    4,设置System为读写权限:mount –o remount rw /system (System默认为只读,无法写入,这一步很关键)

    5,cd到sd卡跟目录下,确认是否有我们拷贝到sd卡根目录下的apk(一般都是 storage/sdcard0)
    shell@android:/ # cd storage/sdcard0
    6,最关键的一步,我们要把apk拷贝到 /System/app中:

    发现copy命令无效~那么我们就用push把:

    如果有错误:device not found,那么手机下载一个Root Explorer把,找到apk,copy到System/app下,通过这个APP要更容易一些。
    7,system/app 确定拥有我们的APK后,重启手机把:

    设置-应用程序管理,查看一下:
    可以看到我们的APP已经无法卸载了,只能停用

    这个时候,就算强制停止,或是关闭Service,重启手机后照样可以起来Service~!


    系统级的APP,这样一些第三方的管家软件,就无法杀掉我们,除非自己把APP停用掉,或是强制停止(但是我的APP可以开机自启动)。

    【结论】这种方式适合调试来用,并不算是一种解决办法,大家可以尝试在正在运行的界面:强制关闭搜狐视频的两个进程,重启手机,发现他又可以自启动,但是如果换成我们的APP,强制停止,进程挂了,再重启手机,无法自启动了~



    大家一起研究,怎么样才能像上图搜狐视频一样,开启两个进程,相互监听,做到最大程度的存活,如果这个能实现了,那就和微信、360等一样的效果了。

    终极解决方案: 使用jni, c端 fork进程,检测Service是否存活,若Service已被杀死,则进行重启Service.
    展开全文
  • 有时候突然忘记某个英文字母对应的进程状态是什么,上网一搜,一堆给你介绍原理和进程状态...D 不可中断的睡眠状态,响应异步信号(例如kill信号能杀死这种进程) R 正在运行或者执行状态(在运行队列上) ...

    有时候突然忘记某个英文字母对应的进程状态是什么,上网一搜,一堆给你介绍原理和进程状态转换的。唉,我只是想简单的知道那个字母对应的进程状态而已,因此自己想写一篇这种很简单的文章,如果想了解那种原理以及进程状态转换的可以不要往下看了。下面开始正文:

     

    D      不可中断的睡眠状态,不响应异步信号(例如kill信号不能杀死这种进程)

    R       正在运行或者可执行状态(在运行队列上)

    S        可中断睡眠状态

    T        暂停状态或者被追踪状态

    W       分页状态(自2.6.xx内核以来无效)

    Z         僵尸进程状态

    I          空闲状态

    X         退出状态(进程即将被销毁)

    有时候我们也会看到进程状态有附加的其它符号,如下:

    因此也对拓展符号解释一下(来自谷歌翻译):

    <          高优先级(对其他用户不好)
    N          低优先级(对其他用户很好)
    L           将页面锁定到内存中(用于实时和自定义IO)
    s           是会议的领导者

    l            是多线程的(使用CLONE_THREAD,如NPTL pthreads创建)

    +          在前台进程组中

     

    这里顺便介绍一种自己查的方式:

    1.man ps 

    2:输入/sleep,按enter键,你应该就会跳到下面这种界面

    3.这里就是man手册关于进程状态的解释了,看不懂英文,没关系,复制下来,打开谷歌翻译,粘贴(强烈推荐谷歌翻译,很好用)

    展开全文
  • 用户空间的进程不会发信号,只要内核空间才可以发信号,linux系统支持64种不同的信号类型 ...上面的代码,执行时自己自己kill。 因此输出状态显示 “Killed”。...D 不可中断睡眠 (通常是在IO操作)
  • 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...
  • Android应对进程被杀死--Service(一)

    千次阅读 2017-01-19 11:42:23
    序言最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己...
  • 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...
  • 序言最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己...
  • 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...
  • 1-服务器安装指定版本pytorch,试了pip安装,结果竟然是找到合适的版本,或许是我搭建的环境的限制,找到1.3.1这个版本,不过好在conda安装是好的。...进行直接kill,无需root权限也可kill自己进程。 ...
  • 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...
  • android的service组件被杀死

    千次阅读 2014-08-28 14:43:12
    最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...
  • 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...
  • 如何让service被杀死

    2016-02-19 14:02:44
    最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...
  • 最近项目要实现这样一个效果:运行后,要有一个service始终保持在后台运行,不管用户作出什么操作,都要保证servicekill,这真是一个难题。参考了现今各种定制版的系统和安全厂商牛虻软件,如何能保证自己的...

空空如也

空空如也

1 2 3 4 5
收藏数 90
精华内容 36
关键字:

进程可不可以kill自己