Allow customization of notification channel names

[franco-zalamena-iterable]

Summary

• Add configuration option for custom notification channel names
• Prevent non-human-readable sound file names from being used as channel names

Test plan

• Test with custom channel name configured
• Test without custom channel name (backward compatible)
• Verify notifications with custom sounds work correctly

🤖 Generated with Claude Code

[franco-zalamena-iterable]

PR Analysis

Problem: When custom sounds are used in Iterable push campaigns, the SDK creates a new notification channel per sound file, using the sound file name (e.g., alert_tone_3) as the channel name visible to users. Users see these non-human-readable names in their device notification settings, and there is no way to customize them.

Ideal fix plan:

• Allow developers to configure a custom, human-readable channel name that overrides the sound-file-derived name
• The custom name should apply to all channels created for custom sounds, so users see a coherent name in notification settings
• Preserve backward compatibility: if no custom name is configured, behavior should remain the same
• Consider whether the channelId logic also needs updating -- the issue mentions wanting "a single notification channel for all Iterable notifications" with different sounds per campaign. Since Android ties a sound to a channel (immutable after creation), a truly single channel with varying sounds per campaign is not possible at the OS level. But at minimum, the channel names should be clean
• Add tests covering the new config option

What the PR did:

• Added a notificationChannelName field to IterableConfig with a builder setter
• In IterableNotificationHelper.createNotification, if the config has a custom channel name, it uses that instead of the sound file name
• Falls back to existing behavior (sound name or default channel name) when not configured
• Added two unit tests for the config builder (default null, and set value)

Assessment:

• Root cause identified: yes -- the sound file name being used as the channel name is correctly identified as the problem
• Fix correctness: partially correct -- the channel name is now customizable, which addresses the cosmetic issue. However, the channelId is still derived from the sound file name (via getCurrentChannelId), meaning a separate channel is still created per sound file. All these channels will now share the same human-readable name, which is an improvement, but users will still see multiple channels in settings (with the same name but different actual sound settings). This may be confusing in a different way. The PR should document this behavior or consider also providing a custom channelId override for apps that want a single channel.
• Missed:
  • No test coverage for the actual notification creation path (IterableNotificationHelper.createNotification) -- the tests only verify the config builder, not that the channel name is actually used when building a notification
  • Accessing IterableApi.getInstance().config directly in the notification helper is fragile. If IterableApi is not initialized (e.g., notification arrives before SDK init), this could throw a NullPointerException. The getInstance() call may return an object with a null config. A null-safety check on the getInstance() return value would be safer.
  • The second part of the user's request (single channel for all notifications) is not addressed. This may be intentional/out of scope, but it is worth noting.
• Wrong assessment: none
• Tests: needed but insufficient -- config builder tests were added, but integration-level tests verifying the channel name is actually applied during notification creation are missing