feat: enhance phone account settings handling for various manufacturers #307
Conversation
|
Hey @bazl-E, great PR and many thanks! If you can resolve merge conflicts I'll merge asap. |
There was a problem hiding this comment.
Pull Request Overview
This PR refactors the openPhoneAccountSettings method in TelecomManagerExtension.kt to provide more robust handling of phone account settings navigation across different Android device manufacturers. The changes extract the manufacturer-specific logic into dedicated helper functions and implement a fallback mechanism to ensure users can access settings even if primary intents fail.
- Replaced hardcoded manufacturer checks with a more extensible manufacturer-specific intent system
- Implemented a cascading fallback mechanism with multiple intent candidates
- Added support for OPPO and Realme devices with manufacturer-specific settings intents
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| val packagedDefaultAppsIntent = Intent(Settings.ACTION_MANAGE_DEFAULT_APPS_SETTINGS).apply { | ||
| `package` = "com.android.settings" | ||
| } | ||
|
|
||
| return explicitIntents + packagedDefaultAppsIntent |
There was a problem hiding this comment.
Setting an explicit package name on an Intent may cause it to fail on devices where the settings app has a different package name (e.g., OEM-customized ROMs). Consider adding a version check or fallback mechanism since Settings.ACTION_MANAGE_DEFAULT_APPS_SETTINGS is only available on API 24+ (Android N) and this intent is used without a version guard here.
| val packagedDefaultAppsIntent = Intent(Settings.ACTION_MANAGE_DEFAULT_APPS_SETTINGS).apply { | |
| `package` = "com.android.settings" | |
| } | |
| return explicitIntents + packagedDefaultAppsIntent | |
| val packagedDefaultAppsIntent: Intent? = | |
| if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) { | |
| // Try to resolve the intent with explicit package, fallback to generic if not resolvable | |
| val intent = Intent(Settings.ACTION_MANAGE_DEFAULT_APPS_SETTINGS) | |
| val pm = activity.packageManager | |
| intent.`package` = "com.android.settings" | |
| val resolved = pm.resolveActivity(intent, 0) | |
| if (resolved != null) { | |
| intent | |
| } else { | |
| // Remove explicit package, try generic intent | |
| Intent(Settings.ACTION_MANAGE_DEFAULT_APPS_SETTINGS) | |
| } | |
| } else { | |
| null | |
| } | |
| return if (packagedDefaultAppsIntent != null) { | |
| explicitIntents + packagedDefaultAppsIntent | |
| } else { | |
| explicitIntents | |
| } |
| } | ||
|
|
||
| private fun resolveSystemComponent(packageManager: PackageManager, intent: Intent): ComponentName? { | ||
| val matches = packageManager.queryIntentActivities(intent, 0) |
There was a problem hiding this comment.
The flags parameter should use PackageManager.MATCH_DEFAULT_ONLY or appropriate flags instead of 0 to ensure only activities that can handle the intent are returned. Using 0 may return activities that aren't actually launchable, leading to potential failures.
| val matches = packageManager.queryIntentActivities(intent, 0) | |
| val matches = packageManager.queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY) |
| } | ||
|
|
||
| val components = listOf( | ||
| ComponentName("com.android.settings", "com.android.settings.Settings\$DefaultAppSettingsActivity"), |
There was a problem hiding this comment.
The escaped dollar sign \$ in the class name string should be a regular dollar sign $ for proper ComponentName resolution. The backslash escaping is unnecessary in Kotlin strings and may cause the ComponentName lookup to fail.
| ComponentName("com.android.settings", "com.android.settings.Settings\$DefaultAppSettingsActivity"), | |
| ComponentName("com.android.settings", "com.android.settings.Settings$DefaultAppSettingsActivity"), |
2 participants
This pull request brings major improvements to the logic for opening Phone Account Settings on Android devices, making the process far more robust and compatible across a wide range of manufacturers and system configurations.
The update introduces:
Manufacturer- and brand-specific handling
Smarter fallback mechanisms
More flexible intent resolution
Together, these changes ensure users are seamlessly directed to the correct settings screen, regardless of their device brand or OS customization.
As part of one of our primary projects, my team and I have been actively using this package — it has been incredibly helpful and reliable. During our integration, we conducted extensive testing across multiple devices and confirmed full compatibility:
✅ SAMSUNG
✅ GOOGLE PIXEL
✅ MOTOROLA
✅ ONEPLUS
✅ NOTHING
✅ OPPO
✅ VIVO
✅ REALME
✅ iQOO
✅ XIAOMI / REDMI
✅ POCO
This update has been thoroughly validated and works great across all the above models.