Nitro's product also does it, but maybe they download the file from themselves or another vendor. Every internet-connected GPS device does it, and this has been the case since even before smartphones took off. If they don't, first fix in a day will take 10-15 minutes of solid reception.

Some GPS chipsets will perform A-GPS internally using a baseband IP stack, but most smartphones actually don't and expect a daemon to handle it since the OS has more sophisticated ways of deciding what network connection to use for the download. This is the most common case for Android, the OS downloads the file and uses a kernel module to provide it to the GPS chipset. The chipset vendors, including Qualcomm here, provide this service as part of their userspace components.

An IIOT LTE module I use has an onboard IP stack and AGPS implementation since it's intended for use in contexts where there isn't necessarily a conventional OS connected to it, maybe just a serial data logger or whatever. The A-GPS requests it makes contain so little data it's a bit comical, the bare minimum for a valid HTTP request. Another reason it's nice to have the OS do it is since that tends to get you access to a more complete HTTP library.

You don't need a third party, you just need to check your network traffic. The issue is that this request is not sent very often because this data is valid pretty long.

But it's basically just fetching https://xtrapath4.izatcloud.net/xtra2.bin with cron (or some other subdomain, depending on the SoC) and uploading that to the gps module so it has atmospheric corrections.