Bump SDK from 30 to 31

[hiqua]

No description provided.

[iSoron]

Thanks, @hiqua!

• API 31 introduced a new permission, SCHEDULE_EXACT_ALARM. I think this might affect us.
• API 31 also restricts launching activities from notifications sometimes. We should check that everything still works.

[hiqua]

@iSoron we can no longer close the notification panel when we snooze a habit. At least not with Intent.ACTION_CLOSE_SYSTEM_DIALOGS.

Since users can now snooze notifications (https://support.google.com/android/answer/9079661?hl=en#zippy=%2Csnooze-notifications), I suggest we just deprecate the later feature from API 31 on. Eventually it'll allow us to just remove the code.

[iSoron]

Since users can now snooze notifications, I suggest we just deprecate the later feature from API 31 on. Eventually it'll allow us to just remove the code

Sounds good. We had disabled the snooze button back when notification snoozing was first introduced (in Android 8?), but eventually brought it back because it was very hard for users to discover that functionality. Android 12 made it more visible, so hopefully we are fine this time.

[iSoron]

Merged, thanks!

[t214c]

I suggest that the snooze behavior is maintained for the following reasons:

1. The system snooze feature have limited options, maxing at 2 hours. LHT offers more options.
2. LHT offers custom snoozing.
3. The system snooze feature doesn't survive restarts. If you had to reboot your phone while a notification is snoozed, it gets destroyed (not shown). There is a standing discussion about enabling better behavior in LHT here (Persist notifications after the restart #923).
   Thanks

[hiqua]

@t214c how do you suggest we deal with the limitations mentioned in #1226 (comment)?

[t214c]

@hiqua I don't know since I am not a developer. If I understand correctly, it is something the user can swipe manually. So, I think missing notifications (It happened to me and I only caught it while reviewing the habit calendar history that I found multiple days unchecked that I was sure I didn't tap "no" on) is more of an issue that not closing the panel

Also, Foxy Droid seems to close the notification panel automatically when it is done checking for repo updates and finding nothing. Maybe this can help?

[hiqua]

Also, Foxy Droid seems to close the notification panel automatically when it is done checking for repo updates and finding nothing. Maybe this can help?

If I read their config correctly, they're using an old API for which (I think) we haven't deprecated the snooze button yet. The problem is for newer versions of Android.

Overall there are pros in having a more advanced snooze feature, I just don't think it's really worth spending efforts on if the OS actually has a basic version of it. Or let's say I won't volunteer to do that myself.

[t214c]

Another app, KeyMapper targets API 32 and has multiple actions to manipulate the notification panel/status bar:

• Expand notification drawer
• Toggle notification drawer
• Expand quick settings
• Toggle quick settings drawer
• Collapse status bar

I am not sure if any/all of these require special permissions. You'd be able to tell.

Or let's say I won't volunteer to do that myself.

I understand. Thanks for looking into it and your volunteer work on LHT. What I am suggesting is that the system snooze feature is just a lacking implementation and the absence of recreating notifications after startup has lead me to miss a weekly habit before.

Tasks already does that recreation of unmanaged notification. Perhaps it could be modelled into LHT?

Thanks

[iSoron]

Another app, KeyMapper targets API 32 and has multiple actions to manipulate the notification panel/status bar:

It looks like KeyMapper uses accessibility services to perform some of these actions. As explained in Android docs, "accessibility services should only be used to assist users with disabilities in using Android devices and apps."

I agree that we should not spend time/effort re-implementing existing OS functionality.

[t214c]

@iSoron Since the feature already exists (the Later button), I was hoping that you would leave it for Android 12.

I am a bit disappointed but I understand your decision. Thanks for the great app.

[iSoron]

@t214c We removed it because it stopped working correctly on Android 12, due to changes made by Google. The button is still there for users on Android 11 and lower.

[t214c]

@iSoron I am confused. Isn't the change in API 31 about disallowing closing the notification panel or is the snooze function itself affected?

[woj-tek]

We removed it because it stopped working correctly on Android 12, due to changes made by Google. The button is still there for users on Android 11 and lower.

@iSoron weird, I'm on Android 12 with uhabbits 2.0.3 and… the "Postpone" feature works brilliantly and even survives restarts. I actually value it A LOT: it offers way more options than system one (which is honestly "half-baked" to say the least) and allow easy personalization, widget to select the postpone time is big and easy to navigate and, as mentioned before - it survives restarts.

I was kinda surprised when I saw changelog mentioning removal of this feature - why remove something that works and do it well (yes, I'm aware about API versioning and google forcing something but still - it works)

[iSoron]

@woj-tek Loop 2.0 targets Android 11 (API 30), so Android 12 (API 31) runs the app on compatibility mode and the feature works. From what I understand, when we increased the target to Android 12 in this PR, and in Loop 2.1, as required by Google Play, the feature stopped working correctly. Since this is already an OS feature, I don't think it's worth spending the time to fix it; but if someone is interested in fixing it, and the fix is trivial, I will consider the PR.

[woj-tek]

Hmmm, so this is a requirement by Google Play store and not the Google/development itself (and also applies after "Starting in November 2022, app updates must target API level 31" )? So if anyone uses F-Droid that would be kinda moot (though, I understand that your main distribution point in Play Store)? Would it be still possible to have 2.1.x release with API Level 30 released before November?

[iSoron]

It would probably take way less effort to fix this feature on API 31 than to maintain a separate API 30 fork for F-Droid users. Also, I expect Loop 2.2.x to target API 33, so the fork would get progressively more divergent and harder to maintain.

[woj-tek]

I have almost zero experience with Android development though just wanted to confirm - running snooze dialogue and actually postponing the notification works fine but closing the notification panel in https://github.com/hiqua/uhabits/blob/1c15e7742ec9722235e790e8a2ae661072cf56c7/uhabits-android/src/main/java/org/isoron/uhabits/receivers/ReminderController.kt#L72 via context.sendBroadcast(Intent(Intent.ACTION_CLOSE_SYSTEM_DIALOGS)) fails thus the snooze widget is not visible?
So this could be this Apps can't close system dialogs:

To improve user control when interacting with apps and the system, the ACTION_CLOSE_SYSTEM_DIALOGS intent action is deprecated as of Android 12

Exceptions

Your app targets Android 11 or lower and is showing a window that is on top of the notification drawer.

Note: If your app targets Android 12, you don't need to use ACTION_CLOSE_SYSTEM_DIALOGS in this situation. That's because, if your app calls startActivity() while a window is on top of the notification drawer, the system closes the notification drawer automatically.

Is this correct? (Just trying to sense if the path is right, and I should dig some more into it :-) )

[hiqua]

@woj-tek that's my understanding, yes.

[woj-tek]

/me is scratching his head.

From the linked documentation context.startActivity() should close the notification drawer. In the showSnoozeDelayPicker() this is already called:

uhabits/uhabits-android/src/main/java/org/isoron/uhabits/receivers/ReminderController.kt

Lines 72 to 78 in 1c15e77

	private fun showSnoozeDelayPicker(habit: Habit, context: Context) {
	context.sendBroadcast(Intent(Intent.ACTION_CLOSE_SYSTEM_DIALOGS))
	val intent = Intent(context, SnoozeDelayPickerActivity::class.java)
	intent.data = Uri.parse(habit.uriString)
	intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
	context.startActivity(intent)
	}

so the last line of the method should also close the notification drawer? If that doesn't work (i.e. notification panel is not closed) then it looks like a bug in Android? Though I'm not sure about this bit: "while a window is on top of the notification drawer" - how can a window be on top of the notification drawer...?

[hiqua]

I suggest you install Android Studio and play with the old code and the deprecated snoozing feature in an emulator to get a better understanding of what the problem is. It's unlikely I or @ iSoron will work on this anyway, so this is mostly not actionable. I don't have the exact details in mind anymore.

[woj-tek]

Hmm, cloned the repo, opened it in Android Studio (master branch), it started the build and failed with:

The project is using an incompatible version (AGP 7.3.0-rc01) of the Android Gradle plugin. Latest supported version is AGP 7.2.2
See Android Studio & AGP compatibility options.

Seems to be caused by f082842, reverting to previous id("com.android.application") version ("7.2.2") apply (false) worked - i.e. gradle sync succeeded but it was still not correctly build/run in emulator because "Unsupported desugared library configuration version, please upgrade the D8/R8 compiler.". Setting val kotlinVersion = "1.6.10" and coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.1.5") fixed the issue... somewhat odd.

I restored removed notification code and I'll play a bit with it, thanks :-)