我使用PendingIntent启动AlarmManager，并且在少数电话上，警报没有响应。在某些设备上可以正常运行，但在其他设备上则失败。我在不同的手机上做了一些测试。
Nexus可以正常工作，三星Galaxy S4 zoom（4.2）也可以正常工作。
三星笔记2（4.3）正常。
OPPO（4.4.4）警报消失。
我还实现了广播接收器，它们可以在所有设备上正常工作。
Log.v(TAG, "START ALARM");
Intent intentAlarm = new Intent(context, AlarmReceiver.class);
PendingIntent pendingIntent = PendingIntent.getBroadcast(context.getApplicationContext(), 0, intentAlarm, PendingIntent.FLAG_UPDATE_CURRENT);
AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
alarmManager.setInexactRepeating(AlarmManager.ELAPSED_REALTIME, 1000, 5000, pendingIntent);
检查应用程序是否处于停止状态。当应用程序处于停止状态时，不会收到任何警报或事件。
另外，我想这可能是OEM /制造商特定的固件/操作系统问题。要检查警报是否已实际调度，请使用adb shell dumpsys警报并检查您的应用警报是否已实际调度。
要检查它是否处于停止状态，请使用以下命令：
adb shell dumpsys软件包“ com.package.name”，然后检查“ stopped = true”
要了解有关停止状态的更多信息，请参阅：
Launch controls on stopped applications
Starting from Android 3.1, the system's package manager keeps track of applications that are in a stopped state and provides a means of controlling their launch from background processes and other applications.
Note that an application's stopped state is not the same as an Activity's stopped state. The system manages those two stopped states separately.
The platform defines two new intent flags that let a sender specify whether the Intent should be allowed to activate components in stopped application.
FLAG_INCLUDE_STOPPED_PACKAGES — Include intent filters of stopped applications in the list of potential targets to resolve against.
FLAG_EXCLUDE_STOPPED_PACKAGES — Exclude intent filters of stopped applications from the list of potential targets.
When neither or both of these flags is defined in an intent, the default behavior is to include filters of stopped applications in the list of potential targets.
Note that the system adds FLAG_EXCLUDE_STOPPED_PACKAGES to all broadcast intents. It does this to prevent broadcasts from background services from inadvertently or unnecessarily launching components of stoppped applications. A background service or application can override this behavior by adding the FLAG_INCLUDE_STOPPED_PACKAGES flag to broadcast intents that should be allowed to activate stopped applications.
Applications are in a stopped state when they are first installed but are not yet launched and when they are manually stopped by the user (in Manage Applications).
请注意停止状态不同于未运行的应用程序进程。
这里可能有几个不同的问题在起作用：
ELAPSED_REALTIME）不会唤醒设备以传递警报。相反，如果在设备休眠时到期，它将在下次设备唤醒时交付。triggerAtMillis的1000值正在设备启动后的1秒内请求第一个警报。如果设备已经启动并运行，并且您请求此警报，则第一个警报可能不会触发，并可能导致后续警报无法安排。这只是一个猜测，我没有通过查看4.4.4 AOSP源进行验证]警报处理已在API 19（Android 4.4）中进行了更改，以处理警报计时器的整理（默认情况下均为不精确），此更改可能会影响第二个项目符号。您可以尝试将triggerAtMillis的值更改为(SystemClock.elapsedRealtime() + 1000)
[请注意，如果您需要设备从睡眠中唤醒，则需要使用_WAKEUP警报变体，还需要让BroadcastReceiver进行唤醒锁定，然后在Service或Activity释放时将其释放处理完警报。
这只是一个猜测，但我认为问题与API有关。从KitKat开始，系统使AlarmManager混乱。也许考虑在kitkat以上的abd的系统上尝试使用其他功能。
“注意：从API 19（KITKAT）开始，警报传递是不精确的：操作系统将转移警报，以最大程度地减少唤醒和电池使用。有新的API支持需要严格传递保证的应用程序；请参见setWindow（int，long ，long，PendingIntent）和setExact（int，long，PendingIntent）。targetSdkVersion早于API 19的应用程序将继续看到以前的行为，在该行为中，所有警报均在请求时准确地传递。
取自http://developer.android.com/reference/android/app/AlarmManager.html
尝试以下操作：
您能否向我们展示AlarmReceiver.class代码？也许您需要在onStartCommand方法上使用return START_STICKY;？
尝试将AlarmManager放入后台服务。
您的警报在正常关闭后将继续存在。如果强行停止它，重新启动设备，安装了应用程序的更新或卸载了应用程序，则它们将丢失。您可以为其中某些情况创建BroadcastReceivers以重新创建警报。
我还在我的项目中使用警报服务在6或7分钟内完成了准备任务。而且在所有手机上都运行良好。
Try this it works when activity is not running..
Calendar calendar = Calendar.getInstance();
long timemills = calendar.getTimeInMillis();
Intent myIntent = new Intent(this, TimeChangeReceiver.class);
pendingIntent = PendingIntent.getBroadcast(this, 0, myIntent, 0);
AlarmManager alarmManager = (AlarmManager) getSystemService(ALARM_SERVICE);
alarmManager.set(AlarmManager.RTC, timemills, pendingIntent);
alarmManager.setRepeating(AlarmManager.RTC_WAKEUP, timemills,
10000, pendingIntent);