yashsingh1/xdaforums huggingface dataset:
[Miscellaneous Android Development] famewolf:
With enough information we could put together a zip that mounted system and set whatever then formatted data to make things simple for the average user. Have you considered running virtualbox and putting the linux disto in that vs an actual partition? You can pass in usb devices which would seem to allow alot of this to work. (I'm just full of annoying ideas. :P )

---------- Post added at 02:07 AM ---------- Previous post was at 01:51 AM ----------

Assuming I did everything right...this should be a flashable zip that installs your twrp to the recovery partition. The problem is you have to HAVE twrp or at least a recovery that will flash unsigned zips for this to be useful. I haven't tried the factory recovery. I threw this zip together to let you get an idea how simple they are...there is a updater script you can view in a text viewer in META-INF/com/google/android.

https://www66.zippyshare.com/v/bK8wAaDZ/file.html

If the system you wanted was in a .img you could do it the same way. It occurs to me you could use adb boot to boot twrp on the phone and then run the .zip to install it permanently.
[Miscellaneous Android Development] FEGuy:
Last time I tried virtualizing anything on Windows 10 I'd get page faults on a near constant basis. If anything I'd rather have a Linux partition as my main and run Windows as the VM, but I don't know how well GPU passthrough actually works on mobile hardware. I wiped enough space on my SSD to get Arch running and mostly doing what I need, anyways.

The zip is helpful, thank you. In the future I'll put up TWRP zips that can either be flashed directly or unzipped and flashed through QFIL, although a bare image is enough for the former. I can also write up a quick script for patching force-encryption rather than doing it by hand, since Magisk and the other zip going around seemed to fail at it.

Unfortunately adb doesn't have the ability to boot images; that's the domain of fastboot, and the R2 doesn't seem to have any support for it. Unless you have some other way of obtaining root permissions for flashing, it seems like QFIL or a similar EDL tool will be necessary at least long enough to flash a patched boot or recovery image, at which point you can use whatever other tools you'd like (aside from fastboot, apparently).
[Miscellaneous Android Development] famewolf:
On the Alcatel Idol 3 they actually took away our fastboot commands and one of the devs had to do something to restore them. I wonder if a similar method would restore fastboot. I'll sit down one afternoon and flash twrp and then do a backup followed by trying one of your alternative rom's....i'll also check to see if I can find a treble compatible Lineageos because it should already have a kernel that can handle the latest magisk. I've just about decided to enable their service for testing and so will want to customize it prior to that.

Anyone found a particular version of google camera with portrait mode and other features that works well with our device?

---------- Post added at 11:52 PM ---------- Previous post was at 11:39 PM ----------

With the 64 bit A only rom here: https://xdaforums.com/project-trebl...i-lineageos-16-0-gsi-arm64-ab-how-to-t3908029

do you have to do any additional patching between getting the rom and flashing it to the device? I'm curious to see how functional it is. Will nandroid work correctly now with the new twrp ie you've tested backup/restore? If you have not tested it I can add a step to test it when I flash twrp.
[Miscellaneous Android Development] FEGuy:
Treble images are GSI - generic system images. By definition, they only touch the system partition; they won't have their own kernel because the kernel resides on the boot partition. As for flashing them, there's generally nothing special that needs to be done, but they're generally only available a sparse image. I don't know if I've screwed up my phone messing with the partitions, but sparse images for /system and /vendor flat-out refuse to flash properly for me; if it's the same for all R2s, you'll probably have to generate a raw image with simg2img, which is quick and painless. From there you can pack them into a flashable zip yourself, use a root shell to dd them directly to the system partition, or use QFIL (the partition manager tool is probably simpler than editing the XMLs for a flat build flash). You'll also have to find and flash a gapps package if you want the Play Store or any other Google apps; make a backup of /vendor first as gapps packages tend to update frameworks there if they find any. Lastly, follow the instructions for the image you want to flash carefully.

As for how well GSIs work in general... I dunno. The AOSP Oreo build I linked to seems to work fine, but a couple different Pie builds didn't - AOSPExtended just kept spinning on its boot screen, and while OmniROM booted, the System UI continuously crashed, making it impossible to do anything beyond completing setup. Probably should've tried the AOSP Pie build or some more Oreo ones before setting my sights too high.

You can do backups and restores of boot, system, cache, and data in the last TWRP build I uploaded, although the data partition has to be decrypted to back it up as I have no idea what the device's default decryption password is or how to pass it to TWRP. Flashing ZIPs works, flashing images to boot and recovery works, flashing images to other partitions isn't enabled.
[Miscellaneous Android Development] s_erco:
How did you get visible to work with your pixel 2 xl? I'm trying to get it to work with my OnePlus 5t. Any information you have on getting it to work with your pixel would be a good starting point.
[Miscellaneous Android Development] famewolf:
Perhaps you could ask your question here since this thread is specific to the Visible R2: https://xdaforums.com/general/help/visible-wireless-android-t3790989
[Miscellaneous Android Development] ConnCarl:
Thanks for posting this! Definitely looking for root/Magisk. From my reading of the thread, though, we're waiting for a reliable method to flash TWRP, correct?
[Miscellaneous Android Development] famewolf:
[MENTION=3540215]FEGuy[/MENTION] and [MENTION=4222965]deadman96385[/MENTION]

Is there a linux version of QFIL(or similar app) available or is it only available from windows?

---------- Post added at 06:39 PM ---------- Previous post was at 06:30 PM ----------

You can use the steps in the 1st post to flash TWRP using QFIL using the files from this post instead of the system rom: https://xdaforums.com/showpost.php?p=79935543&postcount=31 I can't provide a specific walkthrough as I'm on linux and it's a windows program.
[Miscellaneous Android Development] ConnCarl:
Appreciate the response. I'd just use rawprogram_recovery.xml to flash TWRP, correct?
[Miscellaneous Android Development] famewolf:
That's my understanding. If you get a chance please take some screenshots as you go along and perhaps you can share a walkthrough for others to use.
[Miscellaneous Android Development] FEGuy:
Give me an hour or two, I'll have a tutorial up for WIndows as well as Linux (look up qdl in the meantime). I want to push a new TWRP zip first because I forgot to update the XML when I changed the image name (which was also pointless because the displayed name is the same for the new build). Also want to throw together a small script for removing forceencrypt from the /vendor fstab. I'd like to have a patched kernel for newer Magisk up by the weekend but at that point I figure I really need to start a new thread for all this.
[Miscellaneous Android Development] paulCIA:
More or less just stuck a Visible SIM card in it, which they will send you without verifying your IMEI, or with an R2, the same SIM works in both and I can switch service by moving the card, and then fiddled around with settings for a while until it became mostly stable and working

I figured it couldn't have been that different from a 3 XL, and in fact, I don't think all my fiddling with settings actually accomplished much, really all I did was various combinations of reboot, switch between esim and physical sim, and toggle preferred network mode, which in the case of Visible, always needs to include LTE because as I noticed in an area with poor Verizon LTE coverage, if it tries switching off onto CDMA or WiFi assisted calling, the 2 XL goes into emergency call only mode, so apparently there really is some difference because the R2 for example does support WiFi calling. Yet to investigate why or if anything can be done. YMMV with other phones, Id guess as long as it can function in LTE only mode it will be fine though

It usually figures out to reconnect to LTE fast enough, but there are still occasions when LTE signal is bad enough it will switch itself off the network and never get back on, has to be manually toggled either by turning the radio on and off or switching to a non LTE mode and switching back. So there are still a few quirks, but it works good enough for me, and I'm at about -110dBm from 3 separate cells all 120° of azimuth apart most of the time which is about as bad as it gets, so I sure don't blame the phone for being confused what to do.

Everywhere else i go LTE signal is stronger I have no problems and it's faster and doesn't get disconnected, so this is all probably part of a grand plan to nudge customers onto 5G and off of CDMA so they can shut down that infernal thing for good and reclaim the spectrum (and it won't be a day too soon, nobody is going to miss that dinosaur that's for sure, only time I ever had any use for it was at Yankee stadium forcing Fi onto Sprint CDMA because the LTE networks were so overloaded it was paradoxically faster).

I think Verizon is progressively making the whole thing more stable on their end too because it's been working much better lately and i didn't change anything. I just keep a widget up to tell me if it's gone IWLAN and toggle it back to LTE if it did. I'm sure there's an app or I could write one to do it automatically but haven't got round to that either. I did convince QFIL to dump the R2's partitions finally so now to try writing them back with a su binary or rootable adbd... Shouldn't be too hard if it's not actually verifying signatures, hard enough to configure secure boot on your own laptop without locking yourself out so would not be surprised if the devs didn't bother on a non flagship type of phone
[Miscellaneous Android Development] famewolf:
Unless I'm blind then prog_emmc_firehose_8917.mbn is not included in the B12 firmware file so you may want to specify they need the B10 firmware. I'm having to download it now. QDL is installed and I'm going to at least get TWRP installed.

If you can specify where you want that fstab file to fix the encrypted data to go I can setup a flashable zip to replace the file.

At some point a flashable zip to install B12 might be useful so the person's recovery doesn't get wiped. As is you should probably indicate they should do any updates before installing twrp?

That is my far the best most thought out tutorial showing both windows AND linux methods to install I've seen in quite a while. No lie.
[Miscellaneous Android Development] EnumC:
I made the exact same mistake! Might be handy to have both versions on hand, but it definitely takes twice as long to download both files.

Just in case anyone else needs prog_emmc_firehose_8917.mbn by itself, here it is:
[Miscellaneous Android Development] FEGuy:
My bad, I've been playing around so much with the firmware files that I didn't even realize that B12 didn't include the firehose. I was hesitant about adding a link directly to the firehose as I don't know about the copyright, but I've seen enough other uploads around XDA that I guess I shouldn't be concerned. In the meantime, I'll point to the post above this to grab it.

The modified fstab needs to go to /vendor/etc/fstab.qcom, but before making a zip I want to double-check the output from trying to flash a standard force-encrypt and dm-verity remover to make sure that the older TWRP 's fstabs weren't the real issue.

B12 is equivalent to the stock firmware plus the OTA security patches, to my knowledge. Unless the OTAs patch the recovery at some point, being up-to-date shouldn't matter much as we're not breaking OTAs ( I don't think, anyways). I'd be more concerned about an update resetting the fstabs if it's not flashed systemlessly through Magisk or something, and even then I don't know if Magisk would act early enough to load the patched fstab before the device starts encrypting. Either way, I'll double-check to make sure taking an update (at least one that exists at the moment) won't reset recovery to stock.

I'll update the guide tonight when I've got an actual keyboard at hand. I'll probably do a bigger, more comprehensive guide with root, etc. in it's own thread once I've done more stability testing on the patched Magisk-ready kernel.
[Miscellaneous Android Development] famewolf:
I had just noticed that the B12 full rom included the full factory recovery.img and became concerned. In the past on other devices it would sometime check the recovery checksum and if it didn't match it overlayed it with the factory one before proceeding to do an update so we would have to put out modified versions. I wondered if copying and renaming twrp to recovery.img when flashing B12 would bring you current AND add TWRP.
[Miscellaneous Android Development] FEGuy:
I haven't tried flashing the whole package by the phone's recovery; even if it works, it looks like it's designed to blank the userdata partition. If you were flashing from a PC tool, swapping out the recovery.img would work fine. For flashing from recovery, there's likely a signed manifest of each image and its contents - stock recovery would likely refuse to flash a tampered package, although TWRP would likely be fine with it. Flashing the full package, untampered, would definitely reset recovery to the stock image regardless of the tool used, but it's unlikely that an OTA update would do the same. Frankly I haven't viewed it as much of a concern, as reflashing TWRP is a five-minute process once you have the tools and know how to do it.
[Miscellaneous Android Development] famewolf:
The big problem is flashing twrp requires you to connect to a pc that has the appropriate tools installed. What happens if you are away from home and do something that trashes boot or recovery and need to restore things?

*update* Although if the device has been rooted via magisk then you WOULD be able to run something like the app "flashify" to install the flashable zip of twrp.
[Miscellaneous Android Development] PixelVis:
I've managed to do this with a Pixel XL. No wifi calling that I can see for now. Have you ran into any issues with not receiving texts until you restart your phone after it has dropped into an "emergency calls only" state? I noticed mine had dropped into that after receiving a Facebook message from someone trying to get in touch with me. After toggling the LTE only I was able to call as needed. I was able to send texts, and discovered that I wasn't receiving them after restarting my phone. Thinking of utilizing the R2 until they either support my current phone or I save enough to purchase a different device.
[Miscellaneous Android Development] paulCIA:
Yeah if it drops into emergency call mode, means it lost its IMS authentication with the LTE network and can't do anything at all, no text, data, calls, incoming or outgoing. Except of course emergency calls. ;) Fortunately, it doesn't happen very often, some days it never happens, some days I check the log and I see it managed to reconnect itself, but sometimes it does just stay off hook. Probably depends which cell it was connected to when it got dropped.

Also fortunately, I've also found that going to the Phone Info on *#*#4636#*#* , and some combination of either disabling and re-enabling the mobile radio, or switching the preferred network mode into something obviously completely unsupported like TD-SCDMA, and switching it back into LTE only mode tends to fix it.

But it's definitely not 100% reliable. I don't really care because frankly, it's even rarer that I actually want an incoming text or phone call :laugh: and it's a great excuse for why I didn't immediately answer someone's call/text/whatever, whether true or not. :laugh: But if you have important things coming in, yeah it's probably too sketchy for mission critical usage at this point unless someone figures out how to fix that, and I think I've about reached my knowledge of telephony to figure that out!

Likely this can be done programmatically by a watchdog type of app but probably only if you have root and you make it a system app. I can do that in theory but, I have extraordinarily little experience developing on this platform, all the permission/sandboxing stuff drives me crazy (I still have to grant myself all these permissions even if I'm root?) I understand why it needs to exist but it drives me nuts as a developer, I'm normally a backend/systems programmer writing code on machines that cannot take input from "random internet script kiddy", unless they breach the company's whole network and gain credentials and then we have far bigger problems than someone trying to exploit our code, and I've been too busy to learn all about it. But looks like, one could just setup a PhoneStateListener to listen for ServiceStateChange, check if it just went into ServiceState.STATE_EMERGENCY_ONLY or ServiceState.STATE_OUT_OF_SERVICE, and then mess with TelephonyManager or SubscriptionManager but in order to do any of that you need to bypass the sandbox!
[Miscellaneous Android Development] famewolf:
So for folks using the service....other than the lack of customer support how is the actual service doing? Good coverage area? I'm about fed up with T-mobile as half the houses I visit I can't get signal once I'm past the front door and that's in the middle of the frickin town.
[Miscellaneous Android Development] famewolf:
Speaking of FSTAB any thoughts on whether we could adjust the size of the system partition to less than 9GB to free up more space for data? I'm not sure with treble if the system and it's vendor equivalent have to match?
[Miscellaneous Android Development] FEGuy:
No reason it shouldn't be possible, as long as the vendor partition is still large enough to store its current contents or whatever else might change with official updates that you might want to backport in. System should be shrinkable to a degree, but even that's only actually 4GB (the 8.5GB total is spread across a bunch of partitions, most of them tiny) and a lot of Treble images will use 2-2.5 before factoring in Google apps being installed separately, so between system and vendor you'd probably only gain 1-2GB for user storage.

The biggest problem is whether any of the specific, smaller info positions have their locations on the eMMC hardcoded. I'd assume as long as you're just changing the sizes of the partitions and not renumbering the blocks or anything it should be fine, and the fstabs are set up to look by partition name, but you never know. There's a lot of wasted space across the device; the boot and recovery partitions are twice the size they need to be, and the cache partition is an alarming 2GB. Shrinking the cache would be a great starting point, but there are a few smaller data partitions between it and the system partition, so you'd have to tread carefully.

All that said, I have no idea how you'd really go about repartitioning the device, honestly. If you dumped every single partition, shrunk the ones you needed to, and then rewrote the QFIL/qdl XMLs both to flash all the partitions to their new locations and to only allocate the proper, shrunken sizes, you could do it, but I don't know of any simple, parted-like software for Android devices.
[Miscellaneous Android Development] famewolf:
It seems to me like it's all being handled by QFIL and the partition.xml file based on reading here: https://androidforums.com/threads/create-partition-xml-file-manually.1021067/
[Miscellaneous Android Development] paulCIA:
Varies pretty wildly. Here in "random South Jersey cowtown" I usually get about 8mbps up and down, which is pretty sad on the down end but Is actually slightly faster than my Comcrap home internet service on the up. T-mobile definitely faster but they just happen to have a tower located half the distance away from the nearest Verizon tower and it's constantly switching cells because there are 3 or 4 towers all around the same -110dBm power so that can't be good for data. But I haven't had a single call drop anywhere yet and there is at least always service even if it isn't incredibly fast. I used to have Verizon proper years ago but can't remember if it was any different.

On the other hand, at the intersection of West 78th Street and Amsterdam in Manhattan I got 256 Mbits/s down and 33 up so I guess YMMV (quite a lot)
[Miscellaneous Android Development] famewolf:
Well I finally installed some required updates and rebooted my linux box to free up adb. I attempted the tutorial to install TWRP. I'm "KDE Neon" linux which is ubuntu + KDE. I installed qdl via snap. The phone booted into edl without issue however when I got to the next part I encountered issues. All the files including the twrp image are in the current directory. First attempt was on mounted network storage. Second attempt was from the /tmp directory:

famewolf@hp810-135qe /tmp $ qdl

qdl [--debug] [--finalize-provisioning] [--include <PATH>] <prog.mbn> [<program> <patch> ...]

famewolf@hp810-135qe /tmp $ snap list

Name Version Rev Tracking Publisher Notes

core 16-2.39.3 7270 stable canonical✓ core

kde-frameworks-5 5.47.0 27 stable kde✓ -

qdl v1.0-17-ga50ec80 14 stable ondra -

famewolf@hp810-135qe /tmp $ sudo qdl prog_emmc_firehose_8917.mbn rawprogram_recovery.xml patch0.xml

I/O error : Permission denied

I/O error : Permission denied

I/O warning : failed to load external entity "rawprogram_recovery.xml"

[PATCH] failed to parse rawprogram_recovery.xml

qdl: failed to detect file type of rawprogram_recovery.xml

famewolf@hp810-135qe /workarea/android/r2 $ ls

368480B1860Z5151VSBLV1-B12 fstab.qcom prog_emmc_firehose_8917.zip twrp-3.3.1-1-z5151v.img

B10 patch0.xml R2_TWRP-3.3.1-1_Recovery.zip twrp-3.3.1-1-z5151v.zip

'Flash TWRP on Visible R2.pdf' prog_emmc_firehose_8917.mbn rawprogram_recovery.xml
[Miscellaneous Android Development] FEGuy:
Hmm... I'll admit I haven't tried the snap version, and the output seems to be a little different than the version built from source. You're sure all the files are in the directory you're running qdl from? Looks like you're running from /tmp but the output of your ls is from /workarea/android.

If you're sure everything's right, try running with the --debug flag and using absolute paths to each of the files. I'll install the snap and see if it works for me.

EDIT: Nope, I'm getting the same error. Looks like the only solution is to build from scratch, for now.
[Miscellaneous Android Development] FEGuy:
The XML files seem fine. In general I've had more success with qdl than with QFIL, thanks in no small part to the lack of driver hassles. I didn't think to mention it in the guide, but if you're on Windows 10 (or probably even Windows 8) you'll probably have to go through the process of disabling driver verification and/or enabling test signing. I've got my install permanently set up that way due to some unsigned bluetooth drivers for my PS3 controllers, but I'm pretty sure the Qualcomm drivers are similarly unsigned.