[ROM][I777][5.1.1][OFFICIAL] CyanogenMod 12.1 Nightly Builds

[dimoochka]

which kernel we should use for this instructions? can i just replace telecom.apk to /system? i didnt understand how to mount /system on recovery?

1. Any kernel or CM12-based ROM should be fine. Telecom.apk is a system app and is unrelated to the kernel.

Here 's a more detailed instruction list:

1. Make a backup of your existing /system/priv-app/Telecom/Telecom.apk onto your computer.
2. Reboot into recovery.
3. Plug your phone into the USB port, and start adb.
4. In adb, type the following command: mount /system
5. In adb, type the following command: mount -o remount,rw /system
6. Replace /system/priv-app/Telecom/Telecom.apk with my version.
7. In adb, type the following command: chmod 644 /system/priv-app/Telecom/Telecom.apk
8. In adb, type the following command: umount /system

 

[pg1980]

You can also use Terminal Emulator app. I'm using Terminal Emulator app to replace Telecom.apk and it's pretty straight forward.

 

[dimoochka]

Just don't do step #8, "umount /system" if you're using the Terminal Emulator app

 

[fairmount97]

i got one more question..
are there still outgoing call issue on last nightly official?

 

[dimoochka]

i got one more question..
are there still outgoing call issue on last nightly official?

Probably, that bug has been really tenacious and I think I'm the only one that's really spent any substantial amount of time looking into it.

 

[fairmount97]

Probably, that bug has been really tenacious and I think I'm the only one that's really spent any substantial amount of time looking into it.

i think they just use your solve.. can apply this without adb?

 

[TeutonJon78]

@Lysergic Acid, is it possible to get a flashable stock CM kernel with TWRP built for the i777 like you do for the i9100? CM Recovery is just abysmal (esp. for an old device where you need to control more low level aspects to keep it functioning).

Thanks.

 

[fairmount97]

which official nightly is most stable.. You know last one has wifi bug.. Which one i should install..?
Is the Dimoocha's rom (09.25.2015) stable enough? And Can I install TWRP on your Rom Dimoocha?

 

[Lysergic Acid]

@Lysergic Acid, is it possible to get a flashable stock CM kernel with TWRP built for the i777 like you do for the i9100? CM Recovery is just abysmal (esp. for an old device where you need to control more low level aspects to keep it functioning).

Thanks.

Yes, but I won't be able to test it. I'm gonna ask another i777 dev for some help there

 

[dimoochka]

Yes, but I won't be able to test it. I'm gonna ask another i777 dev for some help there

To save you some trouble, I already have this built: http://forum.xda-developers.com/galaxy-s2-att/development/mtp-twrp-2-8-7-0-i777-s959g-t3212309

Not totally "cutting edge" - but less than a month old. I'll rebuild it in about a week to catch up with your kernel changes.

LA, do you want me to provide my code patches? TWRP required multiple patches to work properly on this device.

 

[cyril279]

To save you some trouble, I already have this built: http://forum.xda-developers.com/galaxy-s2-att/development/mtp-twrp-2-8-7-0-i777-s959g-t3212309

Not totally "cutting edge" - but less than a month old. I'll rebuild it in about a week to catch up with your kernel changes.

LA, do you want me to provide my code patches? TWRP required multiple patches to work properly on this device.

Can you tell me more about what your patches do for TWRP?

-Cyril

 

[dimoochka]

Can you tell me more about what your patches do for TWRP?

-Cyril

Yes, aside from creating the twrp.fstab and adjusting the BoardCommonConfig.mk with the proper values (took forever), there were multiple bugs (1-3 are common to all TWRP - I let a maintainer know about it but I don't think if the fixes have ever been merged):

Bug 1: storagename fstab flag value wasn't being evaluated

Bug 2: storagename/backupname fstab flag values would always be interpreted to be prefixed by =" (ptr_len comparator & rval were too small)

Bug 3: If /data is encrypted, a repeat call to TWPartition::Setup_File_System during decryption resets the Display_Name and Backup_Name

Bug 4: (Probably no longer relevant since LA's changes to the i777 encryption footer) For devices that use /efs/metadata to store the /data encryption key, decryption dialog fails to open because EFS is not mounted at the time that TWRP checks for device encryption.

 

[cyril279]

Yes, aside from creating the twrp.fstab and adjusting the BoardCommonConfig.mk with the proper values (took forever), there were multiple bugs (1-3 are common to all TWRP - I let a maintainer know about it but I don't think if the fixes have ever been merged):

Bug 1: storagename fstab flag value wasn't being evaluated

Bug 2: storagename/backupname fstab flag values would always be interpreted to be prefixed by =" (ptr_len comparator & rval were too small)

Bug 3: If /data is encrypted, a repeat call to TWPartition::Setup_File_System during decryption resets the Display_Name and Backup_Name

Bug 4: (Probably no longer relevant since LA's changes to the i777 encryption footer) For devices that use /efs/metadata to store the /data encryption key, decryption dialog fails to open because EFS is not mounted at the time that TWRP checks for device encryption.

Do you have the patch file(s) published anywhere? Or have the changes pushed to a github repository? I am interested to incorporate and try them.

creating the twrp.fstab? I'm not sure I understand, I have been building slim with a twrp clad kernel since 4.4, and things were well established when I started. The boardcommonconfig values may need minor tweaking, but they are not a mystery for these devices.

https://github.com/cyril279/android...mmit/5350153e1d43c6448769bca1357e9a4a33dd95dc

https://github.com/cyril279/android_device_samsung_i777/blob/cyng-5.1/BoardConfig.mk#L37

Edit_______________________________
Omni since 4.3:
https://github.com/omnirom/android_device_samsung_i777/blob/android-4.3/BoardConfig.mk#L37
https://github.com/omnirom/android_...on/blob/android-4.3/BoardCommonConfig.mk#L171
https://github.com/omnirom/android_...on/blob/android-4.3/BoardCommonConfig.mk#L158
https://github.com/omnirom/android_device_samsung_galaxys2-common/blob/android-4.3/common.mk#L23

 

[Lysergic Acid]

To save you some trouble, I already have this built: http://forum.xda-developers.com/galaxy-s2-att/development/mtp-twrp-2-8-7-0-i777-s959g-t3212309

Not totally "cutting edge" - but less than a month old. I'll rebuild it in about a week to catch up with your kernel changes.

LA, do you want me to provide my code patches? TWRP required multiple patches to work properly on this device.

I've previously asked @cyril279 about that, but any of you guys can send me the file I need, if you can grant me your TWRP works as it should obviously. I need the recovery-ramdisk.cpio placed in your /out folder, that's what I'll merge with CM ramdisk and then use it in the kernel.

 

[cyril279]

ramdisk-recovery.cpio:
https://drive.google.com/file/d/0B0R9j8_Y-KixRHBvbDNacUNHSmc/view?usp=docslist_api

 

[dimoochka]

I've previously asked @cyril279 about that, but any of you guys can send me the file I need, if you can grant me your TWRP works as it should obviously. I need the recovery-ramdisk.cpio placed in your /out folder, that's what I'll merge with CM ramdisk and then use it in the kernel.

@cyril279

Here are my patches/source files. Note that this (for some reason) breaks the compiled cm12...-NIGHTLY.zip installer (not sure why). Replacing bootable/recovery with the stock CM12.1 repository seems to restore it - not sure what I'm doing wrong.

twrp-fixes-for-i777.patch should be applied to bootable/recovery
twrp-setup.patch should be applied to build/core
BoardConfig.mk.additions.txt - self explanatory goes into device/samsung/i777/BoardConfig.mk
twrp.fstab.txt - self explanatory. goes into device/samsung/i777/twrp.fstab .... Note: still uses encryptable=/efs/metadata so this needs to be adjusted, just change to encryptable=footer and it'll work with LA's latest encryption commits

Also add twrp.xml in .repo/local_manifests:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <remote name="twrp" fetch="git://github.com/" />
  <remove-project name="CyanogenMod/android_bootable_recovery" />
  <project path="bootable/recovery" name="omnirom/android_bootable_recovery" remote="twrp" revision="android-5.1"/>
</manifest>

... and repo init/sync it obviously.

 

[dimoochka]

Interesting ... I couldn't get PRODUCT_COPY_FILES to work on twrp.fstab. I wonder what I was doing wrong. I had to mess with the build/core/Makefile ;(

 

[TeutonJon78]

To save you some trouble, I already have this built: http://forum.xda-developers.com/galaxy-s2-att/development/mtp-twrp-2-8-7-0-i777-s959g-t3212309

Not totally "cutting edge" - but less than a month old. I'll rebuild it in about a week to catch up with your kernel changes.

LA, do you want me to provide my code patches? TWRP required multiple patches to work properly on this device.

Which is a good effort, but currently not working. Lyseric Acid already has the full working kernel source, has working TWRP for the i9100, and is the developer of the ROM (which no offense, gives him a way higher trust rating to me).

 

[cyril279]

Which is a good effort, but currently not working. Lyseric Acid already has the full working kernel source, has working TWRP for the i9100, and is the developer of the ROM (which no offense, gives him a way higher trust rating to me).

LA is using a prebuilt (by another user/builder) ramdisk to complete the TWRP'd kernel builds. In this case, having a fully functioning, device specific TWRP is better than one that just covers some core functionality, and that's where @dimoochka 's interest, and work, becomes quite valuable. Understanding the code, well enough to fix remaining issues that will extend its use beyond the core functionality is something that we should be encouraging. *especially considering the lack of developer support for this device.

-Cyril

 

[TeutonJon78]

LA is using a prebuilt (by another user/builder) ramdisk to complete the TWRP'd kernel builds. In this case, having a fully functioning, device specific TWRP is better than one that just covers some core functionality, and that's where @dimoochka 's interest, and work, becomes quite valuable. Understanding the code, well enough to fix remaining issues that will extend its use beyond the core functionality is something that we should be encouraging. *especially considering the lack of developer support for this device.

-Cyril

Oh for sure. As I said, I applaud the effort. And if we get a real TWRP and someone maintaining it, all the better.