Setting internal_url merely changes what home-assistant uses if it needs to generate an absolute url for something internal (for example, if sending a url for local media to a chromecast).
Your real issue is that the mdns names are not resolving. This could be because of one of the following reaons:
Docker networking not correct
It is possible for something to have gone wrong with the docker networking configuration such that mdns packets are making it to the hassio-multicast container.
mdns not supported by device
The device in question may not support mdns. For example windows only supports it by default in certain senarios. (To have most regular apps use it, you want to install something like Apple’s bonjour service, which is bundled with iTunes and possibly some other apple software for Windows).
It also looks to me like android does not support mdns for general domain name resolution. (It does support it for programmatically discovering services inside of an app, but normal web browsers don’t use it.)
The almost ideal solution is to have the router provide a dns resolver that supports resolving mdns requests for clients that request these addresses via regular dns. Home network routers almost always provide a stub dns server anyway. Unfortunately, the most common software used for that stub resolver (dnsmasq) not not have the capability.
Further, even though that solution would handle the case of devices that don’t know about mdns, but it could do nothing about the following case.
Wifi router/access point multicast bugs
Sometimes mdns is not available to devices on wifi because a some routers/access points have bugs in their handling of multicast packets. If the device knows about mdns, it would know that .local is specific to link local names, and it is optional to try to also resolve it via traditional unicast dns, so that may not be implemented. This could break things even if your router did resolve mdns for you.
Fixes
Depending on the cause, the fixes could vary.
One potentially workaround that could apply to in most cases is seeing if your router allows setting custom dns entries. If so, setting ‘homeassistant.local’ to the ip address will likely make things just work. Technically though the caveat mentioned in the router bug could still apply if you use .local, if .local is avoided, this approach can avoid all three problems. But of course it only works if your router allows setting dns records to be served. Some do, and some don’t.
As for how to avoid .local: a suffix of .home.arpa should avoid that problem. That is a reserved suffix for home networks, intended to be used by routers that automatically assign domain names for each connected device, but on which there is no restriction on adding additional names.