Play Integrity is focused on checking the OS is original and the runtime environment of the app (your banking app in this case) isn't being messed with. Installing other apps as a developer isn't related to that. If you're not flashing a custom OS or modifying your bank's APK you'll be fine.
(You _should_ be able to use custom OSs and Play Integrity is awful, to be clear - but not because of anything directly relate to normal app development & sideloading)
NB Just to be clear, I'm not doubting you, but if I was in a situation where my life or liberty was at threat I would be very worried about whose advice to take.
If you are not so technical then you have to decide who to trust. For example, you may trust that open source software has been vetted enough and build one from source. Or trust that the built artefacts downloaded from github is good enough. Or trust that the software downloaded from a website not marked as fraud by Google Chrome is good enough. Etc.
In any case, the more technical knowledge you have, the more confidence you can have by doing due diligence yourself.
A primitive way to bypass the censor is just to connect to your VPS with RDP or Chrome Remote Desktop (which is WebRTC underlying) and then browse the Internet there. But it needs a very powerful server and is quite slow.
I didn't fully understand by googling the protocols
How does stealing the certs work without the original private key?
If both sides are ShadowTLS (client & server) holding the same key, they will stealthily switch to a different encryption protocol after the handshake, disregarding the TLS key exchange. The TLS handshake is a facade to fool the deep packet inspection of the censor.
In all other cases, such as the censor actively probing the ShadowTLS server, the server will keep forwarding the encrypted traffic to apple.com without anyway to decrypt it (it's not a MitM proxy). To the active prober, it is just apple.com all the way.
Since China has the most advanced network censorship, the Chinese have also invented the most advanced anti-censorship tools.
The first generation is shadowsocks. It basically encrypts the traffic from the beginning without any handshakes, so DPI cannot find out its nature. This is very simple and fast and should suffice in most places.
The second generation is the Trojan protocol. The lack of a handshake in shadowsocks is also a distinguishing feature that may alert the censor and the censor can decide to block shadowsocks traffic based on suspicions alone. Trojan instead tries to blend in the vast amount of HTTPS traffic over the Internet by pretending to be a normal Web server protected by HTTPS.
After Trojan, a plethora of protocol based on TLS camouflaging have been invented.
1. Add padding to avoid the TLS-in-TLS traffic characteristics in the original Trojan protocol. Protocols: XTLS-VLESS-VISION.
2. Use QUIC instead of TCP+TLS for better performance (very visible if your latency to your tunnel server is high). Protocols: Hysteria2 and TUIC.
3. Multiplex multiple proxy sessions in one TCP connection. Protocols: h2mux, smux, yamux.
4. Steal other websites' certificates. Protocols: ShadowTLS, ShadowQUIC, XTLS-REALITY.
Oh, and there is masking UDP traffic as ICMP traffic or TCP traffic to bypass ISP's QoS if you are proxying traffic through QUIC. Example: phantun.