How to Handle Version Differences in Android 13 Development? Key Tips Revealed!

This article will share my development experience with you,
focusing on the challenges and solutions brought by Android version upgrades.
By analyzing the problems I encountered,
I hope to provide some valuable insights for you when facing similar issues during the development process.

• When targeting Android 13, the system will not send any of the following broadcasts unless the app is started for other reasons:
  • BOOT_COMPLETED
  • LOCKED_BOOT_COMPLETED

• Previously, during development, someone had written a custom writeBytes method which coincidentally had the same name, causing compilation errors.
• If considering upgrading the build SDK, the project owner can consider removing, renaming, or adding public to the method.
  

• If Device Admin permission is granted, it will be permanently disabled if the app is not used. (Self-testing found that if Device Admin permission is turned off, it remains grayed out and cannot be modified)

• Only requesting old permissions will cause a crash, but it can be replaced with All Files Access Permission.
• AirDroid requests All Files Access Permission, so no modification is needed currently. Below is the Intent to navigate to that page:
  new Intent(Settings.ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION);
• For modifications, refer to the demo:

• Since Android 13 disables notifications by default: Official Document on Notification Permission Changes

• Therefore, when executing NotificationManager, the system will prompt to enable notifications.

• For behavior changes, refer to Articles on Adaptation by Netizens

• To handle permissions yourself, you need to upgrade to target SDK 33 to handle the Manifest.permission.POST_NOTIFICATIONS permission.

  Or, when targeting SDK 32, move the initialization of NotificationManager to a later point, but you won’t be able to handle user rejection of Manifest.permission.POST_NOTIFICATIONS.

• target SDK 33 demo patch: Demo