New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to targetSdkVersion >= 26 because of Target API level requirement from late 2018 #66

Closed
udamken opened this Issue Jan 30, 2018 · 2 comments

Comments

1 participant

@udamken udamken added this to the 4.0.0 milestone Feb 22, 2018

@udamken udamken added the enhancement label Feb 22, 2018

@udamken

This comment has been minimized.

Copy link
Owner

udamken commented Feb 25, 2018

https://developer.android.com/about/versions/nougat/android-7.0-changes.html

Test your app on a device with screen width sw320dp and be sure it performs adequately. ** DONE - works fine in emulator with device 3.2 QVGA (ADP2) API 16 **

Apps on Android 7.0 should be able to gracefully handle configuration changes, and should not crash on subsequent starts. You can verify app behavior by changing font size (Setting > Display > Font size), and then restoring the app from Recents. DONE - works fine

https://developer.android.com/about/versions/oreo/android-8.0-changes.html

As one of the changes that Android 8.0 (API level 26) introduces to improve battery life, when your app enters the cached state, with no active components, the system releases any wakelocks that the app holds. DONE - not holding wakelocks at all

All audio-related APIs should use AudioAttributes rather than audio stream types to describe the audio playback use case. DONE - API level dependendy moved to MediaPlayerCompat

https://developer.android.com/guide/topics/ui/notifiers/notifications.html#ManageChannels

Starting in Android 8.0 (API level 26), all notifications must be assigned to a channel or it will not appear. DONE - code changed anyway to attach foreground service to notification

W/Notification: Use of stream types is deprecated for operations other than volume control DONE - API level dependendy moved to MediaPlayerCompat

W/Notification: See the documentation of setSound() for what to use instead with android.media.AudioAttributes to qualify your playback use case DONE - API level dependendy moved to MediaPlayerCompat

https://stackoverflow.com/questions/48381039/intent-filters-https-on-android-8-oreo

As part of the Android 8.0 (API level 26) Background Execution Limits, apps that target the API level 26 or higher can no longer register broadcast receivers for implicit broadcasts in their manifest. DONE - see issue #50

@udamken udamken modified the milestones: 4.0.0, 3.5.0 Mar 31, 2018

@udamken

This comment has been minimized.

Copy link
Owner

udamken commented Aug 11, 2018

https://developer.android.com/guide/components/broadcast-exceptions
https://developer.android.com/about/versions/oreo/background#broadcasts
https://commonsware.com/blog/2017/04/11/android-o-implicit-broadcast-ban.html
https://stackoverflow.com/q/46121467

MindBell relies on the following broadcasts:

android.intent.action.MAIN -- explicit, addresses activity
android.intent.category.LAUNCHER -- explicit, addresses activity

android.intent.action.BOOT_COMPLETED -- implicit but exempted from limitations
android.intent.action.MY_PACKAGE_REPLACED -- explicit, addresses application

android.app.action.INTERRUPTION_FILTER_CHANGED -- TODO implicit, not exempted from limitations
android.intent.action.AIRPLANE_MODE -- TODO implicit, not exempted from limitations
android.intent.action.PHONE_STATE -- implicit but exempted from limitations
android.media.RINGER_MODE_CHANGED -- TODO implicit, not exempted from limitations
com.googlecode.mindbell.UPDATE_STATUS_NOTIFICATION -- TODO Really? explicit, addresses activity

From the second link:

Context-registered receivers receive broadcasts as long as their registering context is valid. For an example, if you register within an Activity context, you receive broadcasts as long as the activity is not destroyed. If you register with the Application context, you receive broadcasts as long as the app is running.

For the time being it looks to me as if this makes constantly showing an up-to-date status notification impossible. Part of this functionality will be moved to Quick Settings (see issue #50).

@udamken udamken closed this Aug 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment