DP5 7.0 - Устраняет ли добавление дополнительных ожидающих намерений?

Question

Добавление связанного вопроса на трекере: https://code.google.com/p/android/issues/detail?id=216581&thanks=216581&ts=1468962325

Так я установил 7.0 релиз DP5 Android на моем Nexus 5X сегодня. Я работаю над приложением, которое рассылает локальные уведомления в определенное время с помощью Android AlarmManager. До этого релиза код отлично работает на устройствах, работающих с KitKat, Lollipop и Marshmallow.

Ниже, как я планирования тревоги:

Intent intent = new Intent(context, AlarmManagerUtil.class); 
      intent.setAction(AlarmManagerUtil.SET_NOTIFICATION_INTENT); 
      intent.putExtra(AlarmManagerUtil.REMINDER_EXTRA, Parcels.wrap(reminders)); 
      intent.putExtra("time", when.getMillis()); 
      PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT); 
      if (alarmManager != null) { 
       if (Build.VERSION.SDK_INT >= 23) { 
        alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, when.getMillis(), pendingIntent); 
       } else if (Build.VERSION.SDK_INT >= 19) { 
        alarmManager.setExact(AlarmManager.RTC_WAKEUP, when.getMillis(), pendingIntent); 
       } else { 
        alarmManager.set(AlarmManager.RTC_WAKEUP, when.getMillis(), pendingIntent); 
       } 

Мои AlarmManagerUtil @onReceive из "SET_NOTIFICATION_INTENT" выглядит следующим образом:

public void fireNotification(Context context, Intent intent) { 
    List<Reminder> reminderToFire = Parcels.unwrap(intent.getParcelableExtra(REMINDER_EXTRA)); 
    long timeToFire = intent.getLongExtra("time", 0L); //.... } 

Что странно это "reminderToFire" равна нулю здесь только на устройствах Android N, но timeToFire правильный.

Я думаю, что это связано с библиотекой Parceler? Я компилирую с использованием Java 1.8 и ориентируясь на Android API 24.

Я определенно оглядел сеть, чтобы ответить на этот вопрос, но мой случай немного уникален, поскольку код 100% работает со всеми предыдущими версиями Android (все ниже N предпросмотр) ... так что я следую ниже ответы столько, сколько я могу:

How can I correctly pass unique extras to a pending intent?

Кто-нибудь еще есть эта проблема?

Answer 1

Для тех, кто в конечном итоге здесь вытягивать волосы над AlarmManager (и не отказались и пошли в JobScheduler пока), Google в производстве API 24 билда не поддерживает прохождение Parcelable объекта в AlarmManager.

Способ, которым я обходился: Если вам нужно отправить список (или отдельный объект) в AlarmManager, сохраните элемент в SharedPreferences в виде строки. (GSS.toJson (объект, тип)). Если объект является интерфейсом, существует ряд решений для интерфейсных адаптеров. Один я обнаружил, плавающие вокруг S/O:

public final class InterfaceAdapter<T> implements JsonSerializer<T>, JsonDeserializer<T> { 

public JsonElement serialize(T object, Type interfaceType, JsonSerializationContext context) { 
    final JsonObject wrapper = new JsonObject(); 
    wrapper.addProperty("type", object.getClass().getName()); 
    wrapper.add("data", context.serialize(object)); 
    return wrapper; 
} 

public T deserialize(JsonElement elem, Type interfaceType, JsonDeserializationContext context) throws JsonParseException { 
    final JsonObject wrapper = (JsonObject) elem; 
    final JsonElement typeName = get(wrapper, "type"); 
    final JsonElement data = get(wrapper, "data"); 
    final Type actualType = typeForName(typeName); 
    return context.deserialize(data, actualType); 
} 

private Type typeForName(final JsonElement typeElem) { 
    try { 
     return Class.forName(typeElem.getAsString()); 
    } catch (ClassNotFoundException e) { 
     throw new JsonParseException(e); 
    } 
} 

private JsonElement get(final JsonObject wrapper, String memberName) { 
    final JsonElement elem = wrapper.get(memberName); 
    if (elem == null) 
     throw new JsonParseException("no '" + memberName + "' member found in what was expected to be an interface wrapper"); 
    return elem; 
} 
} 

После того, как вы адаптер установлен, вам не нужно будет настроить GS0N каждый раз с TypeAdapter, если вы используете какой-то рамки DI (т.е. Dagger2) как так ...

@Singleton 
@Provides 
public Gson providesGson() { 
    return new GsonBuilder() 
      .registerTypeAdapter(YourInterfaceClass.class, new InterfaceAdapter<YourInterfaceClass>()) 
      .create(); 

так все, что вам придется сделать, это запустить ....

/** 
* stores yourInterfaceClass in shared prefs 
*/ 
public void setNextReminder(List<YourInterfaceClass> yourInterfaceClass) { 
    Type type = new TypeToken<List<YourInterfaceClass>>() {}.getType(); 
    sharedPrefs.edit().putString(YOUR_KEY, gson.toJson(yourInterfaceClass, type)).apply(); 
} 

Надеются, что это помогает. Конечно, когда вам нужно получить этот объект из общих префов ....

String json = sharedPrefs.getString(YOUR_KEY, "No object found"); 

Doing типичный объект List = gson.fromJson (JSON, тип) должен работать.

Cheers.

Answer 2

Я видел такое поведение, о котором сообщалось ранее, с пользовательскими Parcelable объектами и системными услугами (например, NotificationManager). Кажется, что система пытается использовать PendingIntent, и как часть этого по какой-то причине она пытается отключить Parcelable. Это не удается, потому что в системе нет ваших классов. Я не слышал о том, что кто-то сталкивается с этим некоторое время, но вполне возможно, что в Android N есть регресс, который повторно представил его.

Вы можете перерыть через LogCat, чтобы узнать, есть ли какие-либо сообщения — или, еще лучше, следы стека — из системы (а не вашего приложения), которые, как представляется, относятся к вашему событию будильника.

Если вы можете создать воспроизводимый тестовый пример, напишите об ошибке the Android issue tracker. Если вы думаете об этом, напишите ссылку на него здесь, так как я хотел бы заглянуть в нее.

С точки зрения обходные пути, я могу думать о двух:

1. Не помещайте Parcelable там. Вместо этого поместите идентификатор, который вы можете использовать для поиска информации по мере необходимости, независимо от того, из кэша в памяти (если ваш процесс все еще существует) или из вашего постоянного хранилища данных.

2. Переключитесь с Parcelable на то, что я и другие назвали «bundle-able», где вы конвертируете свой объект в Bundle. В принципе, придерживайтесь только OS-определенных классов, без пользовательских классов. Затем система может безопасно деактивировать Bundle (по какой бы то ни было причине).Это, конечно, гораздо больнее, чем просто использование обработчика аннотаций для создания реализации Parcelable.

Answer 3

Я нашел, что обертывание Parcelable в Bundle работает.

// When setting up the PendingIntent for the AlarmManager: 
Intent intent = new Intent(context, MyService.class); 
MyParcelable myParcelable = new MyParcelable(); 
Bundle b = new Bundle(); 
b.putParcelable(EXTRA_MY_PARCELABLE, myParcelable); 
intent.putExtra(EXTRA_BUNDLE, b); 
PendingIntent.getService(0, intent, 0); 

// From the Service (or Activity, BroadcastReceiver, etc.): 
Bundle b = intent.getExtra(EXTRA_BUNDLE); 
MyParcelable myParcelable = b.getParcelableExtra(EXTRA_MY_PARCELABLE); 

Однако я не уверен, насколько перспективным является такой подход. Я прокомментировал эту проблему на трекере по ошибке Android: https://code.google.com/p/android/issues/detail?id=209422#c11, но я сомневаюсь, что он получит ответ, так как проблема уже отмечена закрытой.