yashsingh1/xdaforums huggingface dataset:
[AT&T Samsung Galaxy S 4 Android Development] Sterben Pistole:
That's exactly what I noticed. When I saw the IMEI and Baseband showing up as "Unknown" it confused me a bit since I knew 200% that it had nothing to do with the efs partition since I've been flashing back constantly and ended up having working cellular service. I tried seeing if replacing the ril related files did anything, but no luck. It's probably something with how it's trying to access the efs partition. Since this rom was meant for devices that have the loki doki exploit to flash custom kernels I feel like that might have something to do with it, but I'm not exactly sure. I've been doing research on this, but no information that looks like this comes up. It's usually someones efs partition that got messed up somewhere along the line of them flashing the rom, which is obviously not the case with us since we can flash back to other roms and have perfect cellular service. If anyone reading this has any thoughts on this please post in this thread and tell us what ideas you have. Any new information would be greatly appreciated.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
Alright,

I realized one other small piece of information that may be useful to know.

Currently, this build was based on the nightlies I downloaded off of the CM website. When [MENTION=5083211]Evant28[/MENTION] asked me where to download it, I looked for the link, and it no longer existed. It seems that they only keep about 5 nightlies, and as new ones are built, the old ones are gone.

So I downloaded a newer nightly, and made our adjustments, and it would not boot. (Boot loop.)

Then I realized something. My original nightly that I downloaded, to which we have edited and now have partly working, is not for the JFLTEATT. As it turns out, by Evant28 asking me for that download I was able to realize that when I got the phone I was confused as to which variant to download stuff for. The nightly we are working with is from the UNIFIED JFLTE, which officially stopped being supported after CM11. However there are many unofficial ports all the way up to CM13, Pacrom, Slimrom, etc.

I did try downloading a JFLTEATT nightly, made our changes, and put it on the phone, but it did not work. (Boot loop.)

However, I think this helps us to determine the key to opening up the cellular functions. This JFLTE rom somehow has to "choose" the appropriate variant and load the appropriate files. Knowing this will hopefully get us pointed in the right direction.

For instance, our build.prop is not the same between the JFLTE and JFLTEATT variants.

Also of note, it may be possible for future projects to use other Unified JFLTE AOSP roms on our phone. More research is required.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
Which rild and sec-rild?

So in my continued investigation, I have come to the conclusion that the JFLTE rom determines which rild and sec-rild to load at the moment of install. There is a file called "updater-script" in the META-INF folder which directs the rom, while installing the rom, to determine which folder to copy the rild and sec-rild from (verizon, gsm, cdma in the /system/blobs/ folder). The rom is not being supplied this information, and thus cannot determine the proper blobs to load and is loading (I think) the default, which is cdma.

Proof of this concept can be seen on my phone by attempting to flash a CM11 JFLTEATT snapshop or nightly. It will fail to flash claiming that this rom is for JFLTEATT, but that the reported device is " ". At least on my phone.

Oddly enough, while in Safe Strap, I can go to advanced and command terminal and type getprop, and see that the device is JFLTEATT. However the other part of the prop says that it is JFLTEUC. Which is a bit confusing.

So, I attempted to edit my updater-script file, however, it is a series of if/then statements, and I did not edit it properly, causing it to error and fail to flash. Once I get back to my other computer tomorrow, I can attempt to edit that again (with a fresh copy, since now parts are missing on the one I have here) and see if that yields any better results.

This would explain why when I tried replacing the rild and sec-rild in the /system/bin folder of the rom it had no affect, because they were overwritten upon installation with the ones from one of the blobs folder.

I do not know if this will completely solve the issue, but it will certainly help. I am posting this info here in case any of you wish to look into it as well.
[AT&T Samsung Galaxy S 4 Android Development] DeadlySin9:
I am able to flash the JFLTEATT nightly of CM11 without it saying that it's not for my device, but I don't get anything after the Safestrap screen. Both of the getprop commands returned jflteatt, and the part of the updater script that checks which blobs to install is going off the first few characters of the bootloader string (I337UCUGOK2 in my case) which for our devices should always be I337 (if we could change to a different device's bootloaders, we wouldn't have nearly as many issues ;P). Manually copying the libs after install didn't seem to make a difference either. Also, I have still yet to get Wi-Fi to successfully turn on after multiple reboots and hot reboots, but I think the issue is I'm on OK2 bootloader and not OC4 like I thought I was. I don't have school this week so maybe I'll be able to take a backup and flash my bootloaders back and see if things work better then.
[AT&T Samsung Galaxy S 4 Android Development] Evant28:
So sorry, I've been very busy. I'll be back soon to help as much as I can.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
No problem, we all have lives to live! These projects are great, but don't let them rule your life. ;)

See you when you get back!
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
Calling all Jflteatt users with md1 or mk2 bootloaders, if possible, does anyone still run, or is willing to flash a jflteatt CM11? I am looking for a list of the /dev folder. I just realized that the CM kernel that this should work with may have differences in the layout of the /dev folder causing issues. We could use root to symlink around these deficiencies.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
After reading through the META-INF folder, I have changed the updater-script to remove the portions that flash the recovery (which SS didn't allow anyways), and the portions that flash the boot.img (also of which SS did not allow), and removed the portion relating to the LOKI script (since we don't need it). So, sad to say, the Loki script did not cause our problems, and everything works just as it did before. However, this allowed me to delete the /recovery, boot.img, and file_context from the zip, making it slightly smaller, as well as faster to zip between trials. It also gave huge improvements of speed when installing the zip on your phone. So I decided to post the new "streamlined" zip. I will be updating the OP shortly, once the file is loaded to mediafire.....

Be sure to check out the cool graphic while installing in SS. (I think I could have found better uses for my time, but it looks cool.)
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
Flashlight....

While certainly not high on the priority list, I had some time during a break today and can see why the torch.apk app is not working. It doesn't crash, it simply doesn't turn on the led light. Here's why:

# torch
chmod 0666 /sys/class/leds/torch-sec1/brightness

chown system system /sys/class/sec/sec_touchkey/keypad_enable
chmod 0660 /sys/class/sec/sec_touchkey/keypad_enable

chown system camera /sys/class/leds/torch-sec1/brightness

This is taken from the init scripts of the CM kernel boot image. Obviously, these items are not found in our init scripts for our NB1 kernel boot image. I tried adding them to another init script, however it does not work because the /sys/class/sec/sec_touchkey/keypad_enable file does not exist in a /sys partition built by our kernel.

So, one must either replace the torch app with one that functions differently, or rewrite the torch app to use another function, which could be quite a bit of work.

I was thinking of trying the minimalistic open source flashlight in its place, to see if that would work instead as a viable replacement.
[AT&T Samsung Galaxy S 4 Android Development] Sterben Pistole:
I've got a quick question. Do the stock S4 kernels support init.d? It's been bugging me for a good year or since I noticed that the "booster" scripts don't work as expected.

There's a kitchen called ArchiKitchen that claims to add init.d to any rom. Keep in mind you need to have one of the many Linux distros available since, I think, it doesn't have official support for use on Cygwin.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
Not at the moment. Particularly because the init.d scripts are called by the /system/bin/sysinit script.

That script is started in CM11 via init.cm.rc, which is on the boot.img for CM11.

Our boot.img does not include this file, and hence does not call for this script, so it does not invoke the binaries and run the files in init.d.

As you can see from the attached pic, here is the tree of the NB1/NC1 that we do have. Hopefully this tree will help get us on track.
[AT&T Samsung Galaxy S 4 Android Development] Sterben Pistole:
Hmmmm, that's interesting. CM11 is missing most of the init scripts in the SS AOSP roms in the system. Have you tried slapping the missing scripts in to see what happens?
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
I have put them in and updated the OP with a download link for the new zip. It does not have an immediate effect, but it will most likely help. I added some details to the change log also. This may have been why our other attempts / changes did not work....
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
Not all of the Qcom scripts are helping!

So after some testing, I have learned that while all of those scripts were missing, and most of them are in other SS roms, like the GPE roms, not all of those scripts are helpful.

The Bluetooth fails because of the BT and BTDUN qcom scripts, so I have removed them and the Bluetooth once again works. I have updated the OP with a new link.

This does help us though, because we can start using/ruling out some of the scripts that don't apply to this particular rom.

Happy Easter!
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
This works on other AOSP roms also!

Team,

While I do not wish to get distracted from the CM11 SS mod we are building, I did take some time this weekend to apply some of our "workarounds" to another AOSP Kit Kat rom. In this case I tested out AOKP. It would appear that JFLTE Unified development AOSP roms can also be used in SS using the tools we have figured out so far. While there were other bugs present, and some more functional items, the AOKP did boot, and functioned. In that case, the WiFi would work to scan for networks, but would fail if you tried to connect, and the internal storage did not mount properly. So, I do think that the principles of our work here will open up some new avenues for the SGS4 with the locked bootloader.

Now if we could just figure out the cellular part........
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
So, more to learn, more information to share:

An oddity to me while attempting to use the settings menu in CM11 is that it crashes anytime you look at the mobile network settings. It also crashes if you try to look at "about phone" in settings. The text messaging app, message, also crashes when you try to open it. Before today, I had concluded that these errors happened because the radio was not on, causing a crash condition. Now I realize that this is not so.

While testing AOKP KK, all of the above work, despite the fact that there is not a working modem/radio yet. While the radio does not function, you can still open the message app, you can still look at the mobile network and about phone settings.

Likewise, if you remove the sim card completely from any rom, you can still access these settings and apps. It would appear to me that these apps and settings have an error unrelated to the communication with the radio/sim card issue.

It may be that the base rom I chose for porting has issues of its own. To be honest, since I do not have an unlocked bootloader, I am unable to test the original nightly to see if it works under normal conditions. If anyone with an unlocked bootloader or loki-enabled bootloader would like to try it and report back to me, here is the original nightly:

http://www.mediafire.com/download/77m4w21caj0ib7z/cm-11-20151115-NIGHTLY-jflte.zip

And if such an individual was willing, here is a link to the new nightlies for the JFLTE phones:

https://download.cyanogenmod.org/?device=jflte

That would be very helpful to us as you could let us know if the original nightlies have a working radio.
[AT&T Samsung Galaxy S 4 Android Development] Evant28:
Welp, we can't let this die so easily...

Has anyone looked at the report crash button logs? It has a bunch of stuff that I haven't been able to make much sense of but maybe someone who knows more can.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
The problem is not Safe Strap.

As most could probably already assure us, I have proven to myself that the problem with the radio/cellular is not SafeStrap.

I took the time to test both the original nightlies, and our custom rom, as well as a few others without SafeStap by using Flashfire. Flashfire works great by the way. However, the outcome was exactly the same as what we saw in SafeStrap. So, that rules out SafeStrap as having any negative affect on this rom.

Unfortunately, that took a lot of my time, as after these sort of tests I have to rebuild my phone from the ground up. Especially in some of the roms/nightlies where wifi or internal/external storage was not working, and I could not load SafeStrap (because it was wiped) or Flashfire (because I could not load the app).

While I am still working on this, it would seem that unless we get some more assistance, an immediate fix is doubtful. :(
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
No longer actively developed.

Sorry to have to post this, but we can't figure it out.

We've come to a brick wall. We got the rom loading, and several features working, but we can't get the cellular to function. As you know, a cell phone that can't make phone calls isn't worth a whole lot.

We just wanted to let you know that we have officially stopped work on this project. The links will stay up for as long as there is space on my media fire account, and any reading this are welcome to download and play with this as much as you like. You are also welcome to borrow and use anything we've put into the rom if it helps you do anything in your roms.

We apologize for any dashed hopes, ours went down in flames too.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
I no longer have an att s4, but anything I can do to help, just let me know.

Looking back now, this *may* be doable as is.

At the time, we were flashing other modems and boot loader to try to get this working, but that failed. However, now I build roms for the note edge, which requires that I flash data zips to make them work on other variants. Perhaps, if I send you the data zip, but you use the files from your stock att s4, you can flash it after flashing the rom to make the cell work.

Also, task 650’s AOKP kk worked very well for this project also, but has the same issues.

Hope that helps.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
The 0326 version is still up on media fire, if you need to download it.
[AT&T Samsung Galaxy S 4 Android Development] AlaskaLinuxUser:
Great questions.

Um no we didn't use source, we were porting from jflte unified build ROMs.

So we too already built jflte ROMs, downloaded them and modified the files in the zip and flashed them.
[AT&T Samsung Galaxy S 4 Android Development] user someone:
great work mate
[Nexus 5X Q&A, Help & Troubleshooting] mickey4mice:
Hello all,

Seeing MHC19J being the latest update to 6.0.1, I'm tempted to flash factory images like I've done for previous monthly updates (system, vendor, cache, bootloader, radio). Giving all the discussion on MHC19J & twrp v3 related to data encryption, I just want a few clarifications before I go ahead and get myself into trouble.

Here's my current setup:

-Data/Storage Decrypted (formatted userdata using twrp v2.x after unlocking bootloader when I first got 5X)

-MMB29Q - Feb 1 2016 security patch level

-Stock Rooted with Systemless v2.67 beta

-Xposed installed

Here's clarifications I'm looking for:

- will flashing MHC19J automatically RE-encrypt data/storage?

- if so, is there any way to De-crypt it without wiping data/storage? This is important to me because I'd rather keep my phone decrypted for superior performance gains and I don't really have time to reinstall my apps and restore data via Titanium backup at the moment.

If there's no way to decrypt again without completely wiping data, I think I'd rather go with V version or stay on Feb update for now.
[Nexus 5X Q&A, Help & Troubleshooting] SlimSnoopOS:
Flashing any factory image will encrypt your phone as soon as you boot into the rom. Make sure that after flashing factory images, you boot straight into TWRP and flash Super. I flashed every partition as the bootloader and radio are newer. I maintained my decrypt status on TWRP 3.0 after upgrading to MHC19J. Basically, do what you have done every month to maintain decrypt status and you will be fine.

Just do not boot into your system until you have flashed SuperSU.
[Nexus 5X Q&A, Help & Troubleshooting] mickey4mice:
Thanks. Did you use officially released TWRP v3 or the test version posted today?

Did you have to flash Su from OTG or the data partition was okay?
[Nexus 5X Q&A, Help & Troubleshooting] mymusicathome:
I always follow the above post without an issue. I flash the boot.ing also as supersu will patch the kernel when flashed. I used TWRP 3.0.0 and did not have a password prompt and retained unencrypted status. Biggest key is not to boot into the ROM. If you do... It's already too late. Data is encrypted at first boot
[Nexus 5X Q&A, Help & Troubleshooting] SlimSnoopOS:
I used the official TWRP 3.0 from awhile ago. Being that I was decrypted already, official TWRP 3.0 has no issues finding internal storage when moving to MHC19J. No OTG necessary.
[Nexus 5X Q&A, Help & Troubleshooting] KANGOD:
Thanks. Is it enough to just flash SuperSU before boot into rom? I read something like

> You need a custom kernel that doesn’t enforce encryption on boot up. So install custom kernel via TWRP. Erase data partition. Boot up.

> via: www<dot>reddit<dot>com/r/nexus5x/comments/3zctaw/need_help_decrypting/cylsdle

That is, do I need to flash a "custom kernel" besides that flashing SuperSU before boot into rom?
[Nexus 5X Q&A, Help & Troubleshooting] SlimSnoopOS:
Nope. You can flash SuperSU 2.6x only or flash a custom kernel that has disabled "force encrypt." SuperSU also patches the stock boot.img and turns off "force encrypt." Doing either will keep you decrypted.
[Nexus 5X Q&A, Help & Troubleshooting] acsontos:
SuperSu 2.68

I have flashed the new 19J ROM (radio, new boot loader, system, cache & vendor partitions) I left the userdata partition as is, it was decrypted.

I have installed the latest SuperSu 2.68 Beta zip immediately through TWRP (3.0.0-1), Than I have rebooted the system.

After the first boot up, the system is ENCRYPTED! There is no option to decrypt the system in TWRP. It can see all partitions just fine.

Where did I mess it up? How can I decrypt the system without to format the data partition?

I always install monthly updates on the same way, I never had any issues..

thank you

----------------------------------

Update 1:

when I boot into Recovery and I push the "Mount" option I can see the following note

" Data successfully decrypted, new block device '/dev/block/dm-0'

Updating partition details.,..

... done

Successfully decrypted with default password"

When I reboot the system it still shows: The device is encrypted.

Something wrong with the latest SuperSu?

---------------------

Update 2:

I did the exact same thing with my wife's 5X. Her phone is still decrypted after the exact same manual installation. I'm confused. ...
[Moto G 2015 Q&A, Help & Troubleshooting] itfranky1:
Hi,

I have a Xt1541 Moto g3. I used the cm13 rom (one of the version of february) and had no problem. Then, the tragedy: a friend of mine wanted to have free credits in some game and installed the app Liberty, that can hack some inapp payments. I knew this app and i knew it could corrupt the hosts file. So when i found tha playstore not working (no connectio-retry) i wasn't surprised. i deleted the hosts file and rebooted. nothing changed. Then, because a new version of the Rom was online, i flashed the newer version, and now, in the setup wizard, it won't let me access google (it says something like "login failed, could not connect to google servers, try later). I've tried re-flashing deleting cache, re flashing the older versione of cm13, deleting everything after the IP address and "local host" in the hosts file. It always can't access google, same error. I disabled double authentication, removed my device from the devices connected to my google account. i can access my google account just fine from the PC.

Please, help!

Thanks in advance!
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] firerock:
Just saw the news that Modaco has released a guide on how to use ADB to enable your S7 adaptable storage! And no root required, so Samsung Pay and future Samsung update will work as intended!

Can wait to go home and try it.

http://www.modaco.com/news/android/...e-adoptable-storage-on-your-s7-s7-edge-r1632/
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] ilhendo:
Seems to have worked for me. Thanks for sharing.
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] jagman96:
For those who have done this... has your phone slowed down? What card are you using?
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] Binary100100:
Might need to be using this when I get my phone... whenever that will be.
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] tansuperman:
Has anyone done this yet?
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] slickmastajay:
Any feedback guys who have done this? Please provide what card you used so we know.

I'm tempted to do this i have a decent card samsung 64gb pro
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] workingmomjd:
I tried, and instead of coming up with the initial result his did when he ran the sm list-disks command of "disks 179/160", came up with "disks 179/0". I use a 128 evo as well, and it was in debugging mode and had accepted my computer, etc. I ran every deviant I could think of and it changed nothing.
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] Theused1123:
I used an Evo plus 128gb and worked like a charm.
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] Rydah:
What's the purpose of Adoptable Storage? Does it basically turn the memory into one giant "partition?"
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] AUSTIN3:16:
I tried this and never got it to work. Kept showing 179:0 like it wasn't seeing my sd card.
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] burn0u7:
I have a 128gb Lexar high speed MicroSD i picked up from Amazon and i've had zero slow downs. I believe the SD Transfer rate is around 95mb/s so there should be zero issues with it. I did a 50/50 partition according to the guide.

Should note though - some guy says in the comments on MoDaCo's site that you can just download a terminal app and enter the commands directly. well, he's not correct. You can if you have root. Since i actually use Samsung Pay, i am not going to root this device. You need to use ADB as it states clearly in the instructions. That will work fine.

Just FYI.
[T-Mobile Samsung Galaxy S7 Edge Guides, News, & Di] workingmomjd:
Amended to say I tried just skipping to the next step, regardless of the 0, and it worked:) And no slow down so far:)