You state that your application would have limited functionality, even if this "error" occurs. Thus any over-eager error reporting is likely to interfere with the limited-functionality version of the application, either by obscuring it or by accidentally convincing the user that something went wrong and the app is now non-functional.
I would advise against a notification, notifications are intended for messages that are time-sensitive or otherwise critical.
The user is in your app already, why force them out of the app and into the notification drawer? Rather, display an indicator of some sort on the limited-functionality activity. That way the user is notified of the missing connectivity, but is otherwise able to interact with the application normally. Best yet, the user can monitor the status of the connectivity as it changes, from within the app.
To make this answer more generalisable, I've seen about four error reporting mechanisms in general use, and each has their place:
- Inline notification within the application: This is great if the user is expected to be interacting with the application while it is in use, that is, the application is not a background service. It is particularly good if the application continues to function despite the error, as the report is hopefully not intrusive and allows the user to monitor the status of the error as they interact with the application.
- Toast notification: Toasts are temporary notifications, perfect for basic feedback without interrupting the user's interaction or even consuming screen real-estate. They are only useful for feedback if the user is actively interacting with the application, they disappear after a time, and thus are not good for anything but the most minor of errors. Perhaps use them with inline error reporting, to explain the error more fully.
- Dialog box: These should be used with care, they interrupt the user's interaction and demand attention. They are good for errors that demand user intervention or choice, before the application can continue. If the app can continue safely without the user's intervention, these are likely not the right choice.
- Notification: These are "out-of-flow" feedback, perfect for feedback that requires time-sensitive intervention or that might occur when the user is not directly interacting with the application. A failed background download is a good example, while it is not time-sensitive, the user needs to be notified of the error and is not likely to be sitting and monitoring the download.
