[flutter_local_notifications] [Android] Add title & description text styling for notifications (API 24+)

[P8L1]

Hello maintainers

Summary of this pull request

This PR introduces title and description text styling for Android notifications (API 24+).
It allows developers to style the notification title and/or description using decorated custom layouts.
On devices running Android versions lower than 7.0 (API < 24), the plugin will gracefully fall back to the system’s default notification template.

---

Key Additions

[Android] Title & Description Styling (API 24+)

Developers can now customize the title and description text appearance in notifications:

final androidDetails = AndroidNotificationDetails(
  'reminders',
  'Reminders',
  titleStyle: const AndroidNotificationTitleStyle(
    color: 0xFF58CC02,   // Notification title color
    sizeSp: 16,          // Font size
    bold: true,          // Bold text
    italic: false,       // Italic text
    iconSpacing: 2,      // Spacing between icon and text
  ),
  descriptionStyle: const AndroidNotificationDescriptionStyle(
    color: 0xFFFF0000,   // Notification body color
    sizeSp: 14,          // Font size
    bold: false,         // Bold text
    italic: true,        // Italic text
  ),
);

---

Notes

Compatibility:

• titleStyle and descriptionStyle are supported only on API 24+.
• On devices with API < 24, these fields are ignored and the system’s default styling is applied.

---

Tests

Comprehensive tests have been added in android_flutter_local_notifications_test.dart to cover all newly introduced features.

---

Example

---

Request

I’d appreciate your review and consideration for merging this PR.
It improves flexibility for Android developers who want finer control over notification appearance.

Thank you for your time and support.
This is my 3rd pull request since the validation on the previous 2 failed; Java 17 and Kotlin 2.1.0 are not required at all. I included them to avoid warnings when validating

[MaikuB]

A note for future reference that you don't have to close a PR to fix issues found by pipelines

[P8L1]

A note for future reference that you don't have to close a PR to fix issues found by pipelines

@MaikuB Oh, sorry about that—and thanks for the note! This is my first time contributing to open source, so I’m still learning the workflow.

By the way, have you had a chance to review the PR yet? Is there anything you’d like me to adjust?

Also, just out of curiosity, is there a way for me to run the validation pipeline locally, so I can ensure everything works before committing

[MaikuB]

Regarding running the pipeline locally, you can check the scripts run to repeat the same steps. An alternative that I can't verify isn't local but you could use your fork and have the pipelines run on your fork.

As for your PR, I've not had a chance to take a proper look. However, if I'm not mistaken, your PR relies on a custom layout. Is this correct? If so then it's not something I'd be looking to merge in. Key reason for it is it using a general solution to a more specific issue. If the PR itself exposed a way for the others to provide a custom layout associated with their app then that would be more appropriate for the plugin. That would be more in line with the pipeline's purpose on exposing the native APIs.

[Levi-Lesches]

I'll say the XML is very similar to the large layout example from the docs, so it's not that custom, but it is a pretty slippery slope.

Also, maybe this PR can be changed slightly to allow users to provide their own XML files in the res/layout folder like you did, pass in the name of the XML file as a string, then instead of using R.id, use context.getResources().getIdentifier() to find it. That's how the API is currently designed for icons (see here and here). Thoughts?

[MaikuB]

I'll say the XML is very similar to the large layout example from the docs, so it's not that custom, but it is a pretty slippery slope.

Those docs is an example of a custom (notification) layout

Also, maybe this PR can be changed slightly to allow users to provide their own XML files in the res/layout folder like you did, pass in the name of the XML file as a string, then instead of using R.id, use context.getResources().getIdentifier() to find it. That's how the API is currently designed for icons (see here and here). Thoughts?

That is precisely my point. The XML file is a custom notification layout, however the PR appears to have made use of one for a specific use case. I requesting to @P8L1 to confirm in case I had missed something

[P8L1]

I'll say the XML is very similar to the large layout example from the docs, so it's not that custom, but it is a pretty slippery slope.

Also, maybe this PR can be changed slightly to allow users to provide their own XML files in the res/layout folder like you did, pass in the name of the XML file as a string, then instead of using R.id, use context.getResources().getIdentifier() to find it. That's how the API is currently designed for icons (see here and here). Thoughts?

@Levi-Lesches

Yes the goal was to keep the layout the exact same to the default android notifications layout XML.

I have a screenshot below to prove it:

(The colored text notifications uses my code) the rest of the notifications on screen use the built in / default xml

The goal of the PR was simple; Provide a way for developers to change Android Notifications color font size and spacing in flutter (Whilst having the notifications layout being a pixel perfect match to androids built in XML layout). Without writing a lot of code.

Now there are a couple of reasons for me not editing the PR to allow dev's to pass a custom XML.

1. I was on holiday after making the PR and came back a week ago.
2. What are the chances of it being merged (I am sorry, but I put a lot of hard work into my code and putting in hours of work just to see it be rejected is not exactly the best motivator)

So here is my question to @MaikuB

Now that you know my layout renders as an almost
pixel perfect match to Androids built in layout, does that change anything?

If not, if I change the PR so that dev's send through their own Custom XML (like icons) would you be looking to merge it?

Have a great day.

[P8L1]

I'll say the XML is very similar to the large layout example from the docs, so it's not that custom, but it is a pretty slippery slope.

Also, maybe this PR can be changed slightly to allow users to provide their own XML files in the res/layout folder like you did, pass in the name of the XML file as a string, then instead of using R.id, use context.getResources().getIdentifier() to find it. That's how the API is currently designed for icons (see here and here). Thoughts?

@Levi-Lesches

Yes the goal was to keep the layout the exact same to the default android notifications layout XML.

I have a screenshot below to prove it:

(The colored text notifications uses my code) the rest of the notifications on screen use the built in / default xml

The goal of the PR was simple; Provide a way for developers to change Android Notifications color font size and spacing in flutter (Whilst having the notifications layout being a pixel perfect match to androids built in XML layout). Without writing a lot of code.

Now there are a couple of reasons for me not editing the PR to allow dev's to pass a custom XML.

1. I was on holiday after making the PR and came back a week ago.
2. What are the chances of it being merged (I am sorry, but I put a lot of hard work into my code and putting in hours of work just to see it be rejected is not exactly the best motivator)

So here is my question to @MaikuB

Now that you know my layout renders as an almost
pixel perfect match to Androids built in layout, does that change anything?

If not, if I change the PR so that dev's send through their own Custom XML (like icons) would you be looking to merge it?

Have a great day.

Note the font sizes in my screenshot differ from the other notifications. My PR also added a API to change font size. The font size can be changed to match that of a built in / default XML

[MaikuB]

Now that you know my layout renders as an almost
pixel perfect match to Androids built in layout, does that change anything?

If not, if I change the PR so that dev's send through their own Custom XML (like icons) would you be looking to merge it?

@P8L1 The PR would have to change about being able to specify a custom layout and the Dart/Flutter API changes would need to consider compatibility with existing features for it to be merged in. The purpose of plugins like this one is to provide wrappers to native APIs that allow access to general functionality as covered in the native platform's official documentation. In this case, the general notification functionality is around custom (notification) layouts. Currently the PR is making of this feature to solve for a specific case and would therefore be appropriate for forks. If this were to hypothetically be merged in, if the plugin then added supported for using a specified XML then the changes in this PR end up being removed as the general case has been solved and takes priority.

To give an example of what I'm referring in giving consideration to compatibility, the PR implies that it is possible to change the appearance of the title and description and for it to be compatible with Android notification styles. Suppose I updated the example app around showing an inbox notification so the code looks like this

 Future<void> _showInboxNotification() async {
    final List<String> lines = <String>['line <b>1</b>', 'line <i>2</i>'];
    final InboxStyleInformation inboxStyleInformation = InboxStyleInformation(
        lines,
        htmlFormatLines: true,
        contentTitle: 'overridden <b>inbox</b> context title',
        htmlFormatContentTitle: true,
        summaryText: 'summary <i>text</i>',
        htmlFormatSummaryText: true);
    final AndroidNotificationDetails androidNotificationDetails =
        AndroidNotificationDetails('inbox channel id', 'inboxchannel name',
            channelDescription: 'inbox channel description',
            titleStyle: const AndroidNotificationTitleStyle(
              color: 0xFF58CC02,
              sizeSp: 16,
              bold: true,
              italic: false,
              iconSpacing: 2,
            ),
            descriptionStyle: const AndroidNotificationDescriptionStyle(
              color: 0xFFFF0000,
              sizeSp: 14,
              bold: false,
              italic: true,
            ),
            styleInformation: inboxStyleInformation);
    final NotificationDetails notificationDetails =
        NotificationDetails(android: androidNotificationDetails);
    await flutterLocalNotificationsPlugin.show(
      id++,
      'inbox title',
      'inbox body',
      notificationDetails,
    );
  }

This doesn't work as behind the scenes, only one notification style can be applied through setStyle(). This IMO provides a guidance on how the PR can be repurposed. A custom layout on Android side requires using a specific style and this plugin already supports a number of styles that have a mapping and can be specified via this property. I'd envisage that a similar approach can be taken here to add a mapping to that style and the properties allow defining the various custom layouts/views that correspond to setCustomContentView, setCustomBigContentView and setCustomHeadsUpContentView. I have noticed those methods don't require have a style set to work as they're associated with the generic notification builder. IMO it should be fine to have them associated with a style like DecoratedCustomViewStyle on the Dart/Flutter side. It communicates stronger association/coupling and the DecoratedCustomViewStyle API docs reference these methods too. I assume the Android APIs tied it to the notification builder APIs as this style also exists that allows for custom views but is for dealing with media notifications.

These are my thoughts so far and hope they make sense. Happy to answer more questions if you have any