A CSRF attack works by making the browser submit a request to another website. Because the browser automatically adds cookies to outgoing requests, the website will see that you have a valid session (assuming you're logged in at the time) and process the request, even if it came from
evil.example.com. To protect from this, you verify the referrer, or add and verify some token that is not a cookie (commonly called an anti-CSRF token).
By understanding the attack and being an app developer (knowing how apps work), you might already see that CSRF attacks do not apply to apps in the same way.
If you have broadcast events that trigger an action in your app, then of course you should check with the user if they really want to do that, because any other app can trigger it (unless you require a custom permission to trigger the broadcast receiver). It's different from websites because it's intentional: you need to explicitly put in your manifest that "yes, I want others to be able to call this function". On websites, even the "delete user" feature in the admin panel is always exposed, you can't mark that as not being callable externally (anyone can browse to that URL), so to protect a website you need SameSite/anti-CSRF/referrer-checking.
In Android, you can open socket connections and do whatever. It's a proper programming language, not a browser. There is no concept of "same origin", "forbidden content types" or "forbidden headers" because you are the HTTP client, you're not asking the browser to send an HTTP request. And so it doesn't help to set things like SameSite or do referrer checking. But also, your code won't automatically add a security token to outgoing requests triggered by other apps. The only way would be if you explicitly add a broadcast event listener that lets other trigger actions in your app, but even then, the attacker can't specify the HTTP request, they can only trigger your listener to run.
An attacker can't simply (by default) make your app perform a malicious request. Anti-CSRF tokens or
referer checking is not needed. You just need regular user authentication. Because the user is logged in on your app and not on the website, the attacker can't target the app's API from an unrelated webpage. An attacker can't make use of the session token (e.g. JWT) that your app obtained for the logged-in user, because the attacker can't specify a request for your app to add a session token to (unless you program it that way manually).