/e/OS blocks trackers in apps out of the box. AFAIK Graphene doesn't do anything similar.
/e/ has built-in DNS filtering, which blocks a small minority of third party tracking and not the most privacy invasive behavior by apps. It blocks single purpose domains not needed for functionality which were added to their list. It doesn't block any of this when it's on multi-purpose domains with the third party sharing either done server side or required for functionality. Apps can also trivially bypass DNS filtering by doing their own DNS resolution or having IP fallbacks, which many do. However, most simply do the most invasive sharing with third parties server side. App and SDK developers are well aware many people are filtering DNS and work around it.
DNS filtering has downsides including making a VPN not provide the same level of anonymity from websites unless the VPN provides it as a standard feature, since the specific list of blocked domains can be detected.
/e/ doesn't provide current generation Android privacy protections and doesn't keep up with the privacy patches, which would requiring following along with the stable releases of the OS. It doesn't provide privacy features like the GrapheneOS Contact Scopes, Storage Scopes, Sensors toggle and many others. /e/ doesn't improve the app sandbox or permission model like GrapheneOS but rather destroys them. Lagging behind so far on basic privacy and security patches means lack of basic privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand....
Is this you? https://privatephoneshop.com/why-we-no-longer-sell-phones-wi...
The company you've linked was scamming people who wanted GrapheneOS phones by selling them end-of-life devices no longer supported by it and devices near end-of-life while pretending they were perfectly fine and would last years. They were misleading people about what they were getting and violating our trademark. Despite profiting from selling devices with GrapheneOS, they were also actively misleading people about it with many inaccurate claims. Their response to us politely bringing it up was blocking our project account and attacking us. When we warned our community, they responded by joining in with spreading fabricated stories about our team aimed at directing harassment towards us. The videos linked in the article are harassment content filled with fabrications and misrepresentations. The initial video is from someone responsible for encouraging repeated swatting attacks towards our team and the 2nd is from someone who openly uses Kiwi Farms which they directly personally involved to target us.
/e/ leadership spent years trying to mislead people about GrapheneOS including highly inaccurate claims about privacy and usability. We began debunking this and posting accurate technical criticisms of /e/. Despite spending years attacking us with little to no response from us, /e/ has responded to us informing people about it by joining the harassment you've tried to promote. Their CEO / founder has directly participated in it. It's a very typical pattern from /e/ and their community for the response to accurate technical information to be fabricated stories aimed at targeting us with harassment.
There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections
You're firing a starting pistol for a race to the bottom where app developers just end up sending all that information to their own first-party servers instead to be shared with whoever they wanted to anyway.
GrapheneOS absolutely tries to deal with the root of the issue, by giving the user control over sensors and network permissions that return fake/simulated data to keep the app running while denying access to data in the first place. Or contact scopes and storage scopes which restrict access to contact information or storage locations in the first place. As you can imagine, more are planned like location scopes, app communication scopes etc.
/e/ can't prevent tracking by apps and doesn't do it. It has built-in DNS filtering, which doesn't stop the most privacy invasive behavior by apps but rather only single purpose domains for the least invasive tracking making no attempt to evade filtering as explained in https://news.ycombinator.com/item?id=45598100. Any app or SDK wanting to evade DNS filtering only has to use a dual purpose domain, perform their own DNS requests via DoH or fall back to an IP address so many apps and SDKs do those things. However, the most privacy invasive behavior almost always happens through the servers used for app functionality with server side data sharing with third parties. It's not considered good practice to put API keys into the client and do things client side in the first place. There are some exceptions such as crash reporting, analytics and telemetry where that's common which are far from the most privacy invasive behaviors. If they want to evade DNS filtering for those, that's easy.
Location Scopes is a planned replacement for the standard Android Mock Location feature which is rebranded in /e/ as their own feature. /e/ does not have features similar to Contact Scopes or Storage Scopes. It doesn't provide the current generation standard Android privacy protections or patches since it's always very far behind on updates. Most privacy patches aren't backported to older releases, but they lag far behind on backports and don't fully apply them despite claiming to provide a much newer patch level than they do.