Android的未决意图 - 报警 - 同一code六(6)应用程序 [英] Android pending Intent - Alarm - same code six(6) apps

查看:159
本文介绍了Android的未决意图 - 报警 - 同一code六(6)应用程序的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我发现了一些奇怪的昨天。虽然本地化版本测试的应用程序(不同的应用程序-DIF包,同样的code)我发现一个有趣的错误 - 与AlarmManager和正在申请的意向应用程序设置报警 - 当广播发射,只有一个应用程序被激活,执行挂起的意图和所有其他应用程序(仅适用于不同的语言)不反应的。这是Android的错误?我期待这组闹钟将触发有它自己的一套报警,但Android正在启动或最后一个活动的应用程序是由广播触发或接收广播的每一个应用程序?如何被挂起的意图与来自系统的广播相关联的?系统如何知道哪些应用程序是期待广播和哪一个该.apk文件?
它可能似乎很奇怪或很难理解,但林太糊涂..

 公共类AlarmSetter {    公共无效SetAlarma(上下文的背景下){    台历挂历= Calendar.getInstance();
    calendar.setTimeInMillis(System.currentTimeMillis的());
    calendar.set(Calendar.SECOND,57);
    calendar.set(Calendar.MINUTE,59);
    calendar.set(Calendar.HOUR_OF_DAY,23);
    calendar.add(Calendar.DAY_OF_MONTH,0);     意向意图=新意图(背景下,AlarmKicked.class);
     的PendingIntent的PendingIntent = PendingIntent.getBroadcast(上下文,1333333,意向,PendingIntent.FLAG_UPDATE_CURRENT);
     AlarmManager AM =(AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
     am.setRepeating(AlarmManager.RTC_WAKEUP,calendar.getTimeInMillis(),AlarmManager.INTERVAL_DAY,
             的PendingIntent);
    }}


解决方案

OK,等待确认有关的bug

OK,终于!!!!

这是一个LVL BUG:
因此,应用程序是bg.google.myapppackage.apk ..没有错..使用LVL许可证 - ServerManagedPolicy - 定制 - BCS谷歌表示,开发者使用的例子。

在ServerManagedPolicy.java我们有私有静态最后弦乐DEFAULT_MAX_RETRIES =0;我只是做了私有静态最后弦乐DEFAULT_MAX_RETRIES =10;
这意味着10倍的锁定之前开始..没有新的,用户可以在10检查了前..不错启动应用程序,是不是?

但是!问题是在拉特,每次启动由系统非常奇怪的方式登记。如何?只是:
每次启动加号的包,这样

03-17 00:25:45.318:I /软件包管理系统(59):/data/app/bg.google.myapppackage-1.apk更改;拆包

03-17 00:25:45.318:I /软件包管理系统(59):/data/app/bg.google.myapppackage-2.apk更改;拆包

03-17 00:25:45.318:I /软件包管理系统(59):/data/app/bg.google.myapppackage-3.apk更改;拆包

这些都是应用程序启动的时间...好还是没有错..没有!这是错误的!如果你开始从封装bg.google.myapppackage-1.apk的活动,这个包设置报警与AlarmManager你关闭应用程序,之后报警将被解雇,但接收器将没有任何更多的存在.. BCS如果用户关闭应用程序,然后重新启动它,然后我们bg.google.myapppackage-2.apk和第二包装设置报警二,但是当它被关闭beeing包不存在任何更多...该系统的火灾广播但没有接收器和应用程序无响应的。这是在我的情况的问题..测试应用程序,并从来没有广播或仅在活动的应用程序注册的brodcast和其他人没有。

所以,如果你有应用程序,做一些更新,它是由AlarmManager触发,必须设置私有静态最后弦乐DEFAULT_MAX_RETRIES =0;否则为0在重试期间您的应用程序会显示故障,或缺少的功能//我认为,谷歌必须解决与改变包的名称,必须有人张贴BUG票。这件事我计算成本几乎3天(天,我研究它,夜我在家工作..所以睡的是我错过的东西,在失去的时间这样是不想要..)

18 03-14:22:51.860:D /软件包管理系统(199):安装在/data/app/bg.google.myapppackage-1.apk新包装

03-17 00:25:45.348:D / INSTALLD(35):DexInv:--- BEGIN/data/app/bg.google.myapppackage-1.apk'---

03-17 00:25:47.599:D / INSTALLD(35):DexInv:--- END/data/app/bg.google.myapppackage-1.apk(成功)---

03-17 00:25:47.748:I / INSTALLD(35):移动/data/dalvik-cache/data@app@bg.google.myapppackage-1.apk@classes.dex - > /数据/达尔维克-cache /数据应用@ @ bg.google.myapppackage-1.apk @ classes.dex

I found something strange yesterday. While testing app with localization versions(different apps-dif. packages, the same code) I found one interesting bug - the app sets alarm with the AlarmManager and pending Intent - when the broadcast is fired , only one app gets activated and executes the pending intent and all others apps(only different language) are not reacting at all. Is this android bug?? I'm expecting that the set Alarm will trigger every one app that has it's own set Alarm but Android is starting or the last active app is triggered by the broadcast or receive broadcast? how is the pending Intent associated with the Broadcast from the System? How the System knows which app is expecting Broadcast and which one for this .apk? It may seems strange or hard to understand but Im confused too..

public class AlarmSetter  {

    public void SetAlarma(Context context){

    Calendar calendar = Calendar.getInstance();
    calendar.setTimeInMillis(System.currentTimeMillis());
    calendar.set(Calendar.SECOND, 57);
    calendar.set(Calendar.MINUTE, 59);
    calendar.set(Calendar.HOUR_OF_DAY, 23); 
    calendar.add(Calendar.DAY_OF_MONTH, 0);

     Intent intent = new Intent(context, AlarmKicked.class);
     PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 1333333, intent, PendingIntent.FLAG_UPDATE_CURRENT);
     AlarmManager am =(AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
     am.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),AlarmManager.INTERVAL_DAY,
             pendingIntent);       
    }

}

解决方案

OK, waiting for confirmation about the bug

OK, finally!!!!

It is a LVL BUG: So , the app is bg.google.myapppackage.apk .. nothing wrong.. uses LVL license - ServerManagedPolicy - customized - bcs google says the developers are using the example..

In the ServerManagedPolicy.java we have " private static final String DEFAULT_MAX_RETRIES = "0";" I just did " private static final String DEFAULT_MAX_RETRIES = "10";" That means 10 times to start before lockdown.. nothing new , the user can to start the app before the 10 checks are gone.. nice, isn't it?

BUT! the problem is in the LVL , every start is registered by the system in very strange way.. how? simply: every start adds number to the package , like this

03-17 00:25:45.318: I/PackageManager(59): /data/app/bg.google.myapppackage-1.apk changed; unpacking

03-17 00:25:45.318: I/PackageManager(59): /data/app/bg.google.myapppackage-2.apk changed; unpacking

03-17 00:25:45.318: I/PackageManager(59): /data/app/bg.google.myapppackage-3.apk changed; unpacking

those are the times that the app was started... ok still nothing wrong... Nope!THIS IS WRONG! If you start the activity from package bg.google.myapppackage-1.apk and this package sets Alarm with the AlarmManager and you close the app , later the Alarm will be fired but the receiver will no any more exist.. bcs if the users close the app and start it again then we have bg.google.myapppackage-2.apk and the second package sets Alarm two, but when it is beeing closed the package doesn't exist any more... The system fires Broadcast but there is no Receiver and the app is not reacting at all. this was the problem in my case.. testing the app and never got Broadcast or only the active app registered the brodcast and the others didn't..

So if you have app that is doing some update that is triggered by the AlarmManager, you must to set the " private static final String DEFAULT_MAX_RETRIES = "0";" to 0 otherwise in the retries period your app will show malfunction, or missing functionality // I think that Google must to fix that with changing the name of the package and someone must to post BUG Ticket.. This thing costed me almost 3 days(days I study IT, and nights I work at home.. so sleeping is something that I miss, and losing time like this is not wanted..)

03-14 18:22:51.860: D/PackageManager(199): New package installed in /data/app/bg.google.myapppackage-1.apk

03-17 00:25:45.348: D/installd(35): DexInv: --- BEGIN '/data/app/bg.google.myapppackage-1.apk' ---

03-17 00:25:47.599: D/installd(35): DexInv: --- END '/data/app/bg.google.myapppackage-1.apk' (success) ---

03-17 00:25:47.748: I/installd(35): move /data/dalvik-cache/data@app@bg.google.myapppackage-1.apk@classes.dex -> /data/dalvik-cache/data@app@bg.google.myapppackage-1.apk@classes.dex

这篇关于Android的未决意图 - 报警 - 同一code六(6)应用程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆