不再需要ActivityManager - 不是服务问题 [英] No Longer want ActivityManager - Not a service issue

问题描述

我工作的一个开源应用程序（droidwall叉），我坚持的问题之一是iptables的规则无法正常应用系统重新启动时。它完美的作品在大多数的Andr​​oid版本。但在某些特定的ROMS（10.1厘米），它提供了以下的logcat

 八月12号至26号：39：27.116的I / ActivityManager（582）：
不再需要dev.ukanth.ufirewall（PID 2297）：空＃17
 

我的code工作出头像下面，

 专用处理器mHandler =新的处理程序（Looper.getMainLooper（））;
@覆盖
公共无效的onReceive（最终上下文的背景下，最终的意图意图）{
    如果（Intent.ACTION_BOOT_COMPLETED.equals（intent.getAction（）））{
        如果（Api.isEnabled（context.getApplicationContext（）））{
            最终的处理程序烤面包机=新的处理程序（）{
                公共无效的handleMessage（信息MSG）{
                    如果（msg.arg1！= 0）T​​oast.makeText（上下文，msg.arg1，Toast.LENGTH_SHORT）.show（）;
                }
            };

            mHandler.post（
            //开始一个新的线程来启用防火墙 - 这prevents ANR
            新的Runnable（）{
                @覆盖
                公共无效的run（）{
                    如果（！Api.applySavedIptablesRules（context.getApplicationContext（），FALSE））{
                        //错误使防火墙启动
                        最后的消息味精=新的Message（）;
                        msg.arg1 = R.string.toast_error_enabling;
                        toaster.sendMessage（MSG）;
                        Api.setEnabled（context.getApplicationContext（），假的，假的）;
                    }
                }
            }）;
            //开始一个新的线程来启用防火墙 - 这prevents ANR
        }
        / *意图I =新的意图（背景下，StartupService.class）;
        i.addFlags（Intent.FLAG_ACTIVITY_NEW_TASK）;
        context.startService（一）; * /
    }
 

您可以在这里找到我Api.java类

解决方案

  

八月12日至26日：39：27.116的I / ActivityManager（582）：不再想dev.ukanth.ufirewall（PID 2297）：空＃17

该日志意味着，你必须达到最大允许空的过程。 （16是最高你的情况）

更多关于空的过程，从机器人DOC 的：

  

一个不举行任何活动的应用程序组件的过程。保持这种进程活着的唯一理由是缓存的目的，以提高启动时间，下一次一个组件需要在运行它。该系统往往杀死为了处理的高速缓存和底层内核缓存之间的平衡系统的整体资源这些进程。

所以，不知道登录你的直接替换iptables规则涉及到您的问题。

I am working on a open source application (droidwall fork) and i am stuck with one of the issue were the iptables rules were not applied properly when the system reboots. it works perfectly on most of the android versions. But on some specific ROMS (CM 10.1) it gives the following logcat

12-26 08:39:27.116 I/ActivityManager(582): 
No longer want dev.ukanth.ufirewall (pid 2297): empty #17

My code works somethings like below,

private Handler mHandler = new Handler(Looper.getMainLooper());
@Override
public void onReceive(final Context context, final Intent intent) {
    if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) {
        if (Api.isEnabled(context.getApplicationContext())) {
            final Handler toaster = new Handler() {
                public void handleMessage(Message msg) {
                    if (msg.arg1 != 0) Toast.makeText(context, msg.arg1, Toast.LENGTH_SHORT).show();
                }
            };

            mHandler.post(  
            // Start a new thread to enable the firewall - this prevents ANR
            new Runnable() {
                @Override
                public void run() {
                    if (!Api.applySavedIptablesRules(context.getApplicationContext(), false)) {
                        // Error enabling firewall on boot
                        final Message msg = new Message();
                        msg.arg1 = R.string.toast_error_enabling;
                        toaster.sendMessage(msg);
                        Api.setEnabled(context.getApplicationContext(), false, false);
                    }
                }
            });
            // Start a new thread to enable the firewall - this prevents ANR
        }
        /*Intent i = new Intent(context, StartupService.class);
        i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        context.startService(i);*/
    }

You can find my Api.java class here.

解决方案

12-26 08:39:27.116 I/ActivityManager(582): No longer want dev.ukanth.ufirewall (pid 2297): empty #17

This log means that you have reach the maximum allowed empty processes. (16 is the max in your case)

More about empty processes from android doc:

A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.

So, not sure the log you have is directly related to your issue with iptables rules.

这篇关于不再需要ActivityManager - 不是服务问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！