Api 31

[hannesa2]

close #3485

includes #3581

[hannesa2]

Sorry, I've no clue what's wrong here. On my fork it works properly, but there I've a lot of additional (unrelated ?) changes too.

But ignoring this api31 will stop other dependabot changes.

[hannesa2]

It builds now properly, even local on Apple Silicon M1

[jesmrec]

Will check the impacting new features with API 31 and older to assure nothing is broken

	Android 12
Custom Notifications	Forcing an upload to fail, notification is correct.
Toast Redesign	Toasts are being removed from app. Anyway, a check with the remaining ones was correct
Modern SameSite cookies in WebView	oC webViews don't use SameSite
App hibernation	No testable. System feature
Safer component exporting	every intent-filter contains android:exported.
Pending intents mutability	Flags always immutable
Unsafe intent launches	unparcels a nested intent from the extras of a delivered intent. Your app immediately starts an app component using that nested intent, such as passing the intent into startActivity(), startService(), or bindService().
Notification trampoline restrictions	Click on failed upload notifications, should open the uploads view

[jesmrec]

First appreciations:

Safer component exporting:

As the documentation states:

If the app component includes the LAUNCHER category, set android:exported to true. In most other cases, set android:exported to false.

every intent-filter contains android:exported = true even if it is not a LAUNCHER like presentation.ui.sharing.ShareActivity or .authentication.AccountAuthenticatorService. I guess that the true value is mandatory por LAUNCHER and for the other, it depends, right?

Pending intents mutability:

our intents are always immutable, right?

 val pendingIntent = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
            PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_ONE_SHOT
        } else {
            PendingIntent.FLAG_ONE_SHOT
        }

could this affect the functionality somehow?

Unsafe intent launches

does the app do this? (as the docum):

Your app unparcels a nested intent from the extras of a delivered intent.
Your app immediately starts an app component using that nested intent, such as passing the intent into startActivity(), startService(), or bindService().

Foreground service launch restrictions

Apps that target Android 12 or higher can't start foreground services while running in the background, except for a few special cases.

is any of the listed exceptions important to take in account?

non-SDK restrictions

is there anything that should be tested, regarding your comment -> #3485 (comment)

[jesmrec]

QA Checks

• Auto uploads in background (both photo and video)
  • Regular uploads
  • Only Wifi
  • Only Charging
• Share with oC using different apps
• Document provider (create folder, copy from, move to, delete, rename)
• Upload/Download notifications
• E2E Automatic tests

[jesmrec]

I tried to put the focus in those features that use the system (checklist above), checking with different devices (Android 12 and older). Basic features work fine.

Since a new SDK could affect any part of the app, apart of the testing done in this PR, a beta version is recommended to expand the scope.

Bumping the DAV and networking libraries will help to fix #3485 (comment)

Extra testing will be done in regression stage.

This one is approved on my side. Thanks @hannesa2 and @fesave for the great work.