So...

1. If Apple doesn't implement Signal and if they don't contribute to the RCS protocol (they can do it, the same way as they do for the Qi charging thing, they did contributed to the same type C standard they were avoiding all this time, they do contribute to av1 codec etc etc)
2. And at least one of the 2 service providers does not have RCS implemented yet

then the info will go through google eventually, and if it is not e2e, then Google will see it.

Just a reminder, they do currently send SMS to android, and sms is fully unencrypted and fully visible to virtually anyone (including to google and everyone in the country on the receiving end).

I doubt Apple will ignore e2e just to flip Google with "green bubbles are insecure, use iMessage". And people (if they are not Pavel Durov of Telegram) have a lot of faith in Signal protocol, so they don't have to revolutionize anything - there is a good enough thing to implement.

And if Google and Apple both use Signal on top of the standard, it will become standard.

P.S. messages via pigeons are waaaaaay more secure than SMS. For a fun time, search for something like "examples of SS7 vulnerabilities / attacks" and enjoy reading. That's why 2G, parts of 3G and SMS must die - SS7 is insanely broken (it was created before security was invented as a word)

Oversimplified:

GSMA created a RCS - that is a protocol. Then they released a "basic spec"- Universal Profile. Anyone who implements this spec can guarantee that their RCS messages will work with anyone else's messages.

Some internet providers, network manufacturers, some OEMs implemented Universal Profile (UP here and next) in their systems. And also Google and Microsoft announced they have done Universal Profile too. Check this list of parties that created their own thing, with a UP = they are all working together

So. At this point in history you have nothing to do with Google. If you want to receive and send RCS, you have a spec to follow and a protocol to use. Everyone else with UP will be able to communicate with you. You can add some nice things above UP, with the understanding that only your clients will enjoy them. Think about it as AOSP (bare android) vs Google's pixel android vs Samsung's android vs Xiaomi's thing. They are independent, but they have some specs to follow, and it is still android behind the doors.

At some point in time Google said to providers: "Either you are joining the movement and create your own infrastructure with UP spec to work with RCS (and then the "text messages" are still going through your provider, as the SMS do), or we will transfer the messages via our own servers (since you don't support the protocol to move them through you).

This was criticized, because GMSA's RCS protocol does not support e2e encryption. This is ridiculous complain, because SMS are not encrypted and ARE FULLY VISIBLE TO ANYONE including your provider, and a hacker with 100 dollars to spend on SS7 attacks. If you are not a hacker, in our and other countries there is a subscription model for SS7 vulnerability based "hacks".

Anyways. Google said ok, and implemented Signal protocol for e2e above RCS. Think again about difference with AOSP android and Pixel android - you can have nice things on top.

So. Nowadays. There is a Messages app on your phone. If you want to, it will send RCS. Because it is Google's version, it supports e2e. If your provider has implemented RCS, the message goes through your provider (as the rest of SMS). Most providers don't bother, so the RCS goes through Google's servers. Since right now you're only sending RCs between a Google's version to a Google's version, everything is e2e encrypted (and evil google won't read this tiny bit of your information on top of everything they know about us 😌).

If Apple implements RCS, the situation will be similar. Apple will use their app to send RCS to non-imessage contacts. Providers with RCS support will handle the messages (just like they do with SMS). Otherwise Apple will handle their part and on the receiving end a provider with RCS support or google do the rest.

Important note: protocol as it is written is not e2e. So if Apple continue to be pricks, they will implement the bare minimum and will say: "Use imessage, it is safe, don't use green bubbles, they are unsafe". The other option: they can push GSMA to update the protocol with e2e. Or they can adopt Google's version with Signal protocol on top. Sometimes this happens with specs - a large player can force everyone to support extra features.

If you're from the US, you're probably burnt by your mobile providers. I don't believe I've heard any horror stories about esim in my country and our neighbors (except for the fact that you still have to pay $3-5 to switch to "esim", as if you are getting something besides a string of numbers)

Here is my use case: 0. I have a device with 1 sim slot

1. I have my main physical SIM-card with a known number (relatives, work partners etc). I have some data there as well. This is my "daily driver"
2. I have a separate e-sim with an "unknown" number that I use for sms-verification things for web services. It also has some dirt cheap data (but the coverage is not great).

At least on Pixel phones you can have a physical and e-sim card both active at the same time, and you can choose, for example, "sms and calls default to 1, mobile data default to 2". There is an option to "switch to another sim for data, if the signal is bad. (There are talks about simultaneously active several e-sims, but it's not here yet)

Even if you discard a security angle (sms verification should not be a known number - "restore sim" attack is quite common for a targeted action), a lot of people can benefit from "1st physical sim has great calls plan/ coverage, 2nd sim has cheap internet"

Hmmm, how about this:

Only apps with root can see the private app data in /data/data/ or /data/user/*/ that stores your app preferences, login info, databases, etc.

Without root, you can have some extra permissions by installing Shizuku - you will need adb to grant Shizuku those rights (this app is used to give those permissions to other apps supporting Shizuku - check those here https://github.com/ThePBone/awesome-shizuku ). For example Swift Backup works best with root, but without it it can still backup at least external app data (located in Android/data)

You used to be able to do proper backups via adb, but now you rely on app devs using proper backup methods via Google drive thing, and very few of them do.