L2 "solutions" are never the answer to the problems rooted in L1. They are merely crutches. And crutches tend to break over time.

And also, are there any options of buying a virtual PSTN number for SIP calling with crypto (and non-KYC, of course) and topping it up with crypto as well? I know about JMP.chat but I need SIP, and not in an experimental status, and I shouldn't be charged for *incoming* calls, no carrier does this here. I could have stuck with my Intertelecom number but I need to get more global. #asknostr

Ok, so CSipSimple, Lumicall etc are pretty much dead on Android 14. Linphone and SipDroid are alive, bu the second one is unusable. So, which FOSS alternatives of Linphone exist at this point?

Great to see people go against the square-holed mindset imposed by googles.

GitHub

GitHub - akavel/hellomello: Experiments with writing Android apps in Nim

Experiments with writing Android apps in Nim. Contribute to akavel/hellomello development by creating an account on GitHub.

I guess the best "traditional" on-screen keyboard application for Android would be Unexpected Keyboard. It's FOSS, it's convenient, it adds everything on par with the PC input (even a dedicated Compose key) and is extremely configurable.

Hmm. The devinfo partition does indeed store both Pixel 6 IMEIs in plain ASCII. They can be found after "imei1" string and zero byte and after "imei2" string and zero byte respectively. Patching any of them in the devinfo image, regardless of whether or not /mnt/vendor/efs/nv_protected* files are deleted afterwards, causes the device to report both IMEIs as 000000000000000 to both the OS and the network (which shows "Unknown Unknown" in place of the phone model in the carrier's account page). Other places to properly patch the IMEIs in addition to the devinfo partition are still being researched. The journey is still far from the end, but, according to some "experts" from the #GrapheneOS forum, even this couldn't be possible because, you know, ReGuLaTiOnS.

Did you know that POSIX standard specifies offset display support for "strings" utility?

strings

Very useful for pure-shell-based patching of some text in binaries (in combination with dd, of course)

OK, temporary IMEIs working. Not every time (those damn AT command timeouts or whatever) but I did see another model on my carrier's page. #GrapheneOS spokespeople were wrong, and it's just the beginning of my quest. The Graphene Saga: part 1 https://hoi.st/posts/2024-03-11-the-graphene-saga-part-1.txt

Ok, I might have found at least something regarding IMEI editing in Pixel 6. The most interesting part is that I **had to** use my carrier's personal account page to verify the change is successful (by viewing which phone model the carrier detects), because whatever is displayed at `*#06#` or `*#*#info#*#*` does not change with this hack. So my method is going to only change whatever the network sees. Exactly the opposite to what those buffoons were stating. Stay tuned.

Found a nice onion-enabled shell service, finally the one where free limits look reasonable:

The Hacker’s Choice

Segfault

Disposable Root Servers.

Of course, one can never be fully sure what they are really monitoring, so be careful.

Modern Android's toybox shell has AWK preinstalled. That's pretty good. Of course, Termux has AWK too, but that's not as interesting as the fact that Exynos 5123 has a third hidden IMEI. Of course it's unused in Pixel 6, but demonstrates a theoretical possibility of putting a second physical SIM slot in addition to the first one and eSIM. The truth is very close. I hope this Saturday wasn't spent for nothing.

I mean, are they probably afraid that someone is going to have a degoogled AND rooted AND hostile work environment\* ready Android flavour to just enjoy their devices while being in full control of them? \* I mean an environment enforcing Intune Company Portal and other similar anti-freedom bullshit

I'm not an Android developer. I don't want to become an Android developer. I don't want to know how to build various crap for Android 14, or any Android beyond 6, for that matter. I deeply hate Java and any other similarly square-holed programming languages with long names, tons of boilerplate and mandatory semicolons (the only language that gets a pass for them from me is pure C). I deeply hate any XML-based build systems and all the bloatware around them. It's all a complete mess at this point. Yet I, instead of trying to relax on the weekend, have to (re)learn all this just to be able to make one FOSS project work on another because the developers of both of them turned out to have an extremely assholian attitude. And then, if/when everything works as expected, I'll also have to spend some time and resources to host my own forked repo (of course it won't be on GitHub or even SourceHut) and the release APK as well. And it will be a one-time effort, I physically won't be able to patch out any further versions anyway. All this because I want my smartphone to function like a full-featured pocket PC, not like a consumeristic black box. Is this so hard to understand?

The simplest and most reliable way of dropping some short text from PC to Android (as long as they are in the same LAN) is: 1) Run Termux and note your current IP with ifconfig. 2) Run nc -l -p [someport] on the Termux side. 3) Run echo 'yourtext' | nc [android_ip] [thatport] on the PC side. 4) Quit nc on the Termux side and copy whatever you received from the terminal window. Of course, with longer texts, you can just redirect the output to a file and use cat instead of echo on the PC side. You can also install Termux:API Android package (and termux-api from Termux itself) to leverage termux-clipboard-set command to automate the last step.