Related
Hi,
I try to modify the framework-res.apk.
It is working fine for the ROM I'm using (OpenDesire on a HTC Desire) but I don't want to flash a new framework file to my phone just to see how it looks when applied to a phone.
So I pulled the framework-res.apk from the running emulator
adb pull /system/framework/framework-res.apk .,
modified it and pushed it back to the emulator:
Code:
adb push framework-res.apk /sdcard/
adb remount
adb shell
# cd /sdcard
# dd if=framework-res.apk of=/system/framework/framework-res.apk
# exit
After the dd the emulator restarts and gets caught in a bootloop. Is there a working way how I can change the framework-res.apk?
Don't take my word for it, because I'm not 100 % sure -
But pushing framework-res doesn't work. If you were to do that on an actual device you'd get bootloops or 90 % of the apps would Force Close - Resulting in yet another bootloop.
If you've got a Desire you can use The Online Theming Kitchen.
www.circle.glx.nl
zHk3R said:
Don't take my word for it, because I'm not 100 % sure -
But pushing framework-res doesn't work. If you were to do that on an actual device you'd get bootloops or 90 % of the apps would Force Close - Resulting in yet another bootloop.
If you've got a Desire you can use The Online Theming Kitchen.
www.circle.glx.nl
Click to expand...
Click to collapse
On my device (it is a HTC Desire) I do push the new framework in recovery. But I don't want to push a new framework to my phone every time I have changed some graphics. That's why I want to test it on the emulator first. But I can't get it to work on the emulator
I'd like to make a few changes in the services.odex file, and I want to make sure I do it correctly the first time, so I'd like to run this by everyone for comments/corrections.
So far, these are the steps that I *think* are correct:
1. Pull /system/framework/* files onto my PC.
2. On the PC, baksmali the services.odex.
3. Makes the changes to whatever .smali file I wish.
4. Rebuild services.dex via smali (using the output dir created by baksmali).
5. Insert services.dex into services.jar (using, say, WinRAR).
6. Push the new services.jar onto /sdcard and then copy it over to /system/framework dir.
7. Reboot and pray it works.
Is this correct?
---
EDIT: See my reply below for the answer.
Should I post this question over in the "Captivate Android Development" forum? Anyone?
Small bump for this post, interested in the correct procedure for this too.
[A] Here are the steps
Yeah, it took me a week of digging to find this answer.
Disclaimer:
1. Proceed at your own risk and don't blame me if you brick your phone.
2. While I've done my best to document the steps I took, there's always a chance I've mistyped something.
3. If you're unsure at any point, STOP! Re-read everything so you fully understand what you're doing.
4. Editing .odex files can be extremely tricky! All it takes is a bad edit to royally screw up your phone.
This guide assumes:
* you have a Captivate and it's running stock Eclair. (Don't know about other phones or other OSes.)
* you have rooted your phone, and have busybox & Superuser Permissions installed.
* you have adb installed and working on a PC.
* you have baksmali and smali installed and working on a PC (along with Java).
* you have downloaded the utility "dexopt-wrapper". (Do a search - you'll find it.)
* you know what the BOOTCLASSPATH value is for your phone. (Hint: It's in /init.rc)
* you have made a complete backup of your phone! (Yes, if something goes wrong, it's much nicer to be able to restore files from a recent backup than to have to wipe the phone and start from scratch again.)
- I highly recommend you install ROM Manager w/ ClockworkMod. (And don't delete /sdcard/update.zip)
Notations:
When you see a line beginning with >, that's a command to be executed on the PC.
When you see a line beginning with #, that's a command to be executed on the phone.
Ready? Here we go:
put the dexopt-wrapper onto your phone.
> adb push dexopt-wrapper /sdcard
copy all of the /system/framework files onto your PC.
> adb pull /system/framework
let's pretend you want to change something in services.odex.
decompile the .odex file
> baksmali -x services.odex -o services.out
now edit whatever .smali file you want in the services.out folder.
rebuild the classes.dex file for services.odex.
> smali -o classes.dex services.out
now put classes.dex into services.jar (I used WinRAR, but other ZIP utilities should work.)
put the new .jar file onto your phone.
> adb push services.jar /sdcard
> adb shell
become super user
# su
put the dexopt-wrapper utility into the bin folder with the correct permissions. (you only need to do this once, obviously.)
# cd /system/bin
# busybox cp /sdcard/dexopt-wrapper .
# busybox chmod 755 dexopt-wrapper
# cd /sdcard
create a new .odex file from the new .jar file
# dexopt-wrapper services.jar new.odex [BOOTCLASSPATH]
yes, fill in the value of BOOTCLASSPATH, without the []
here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
hint: the file size of the new.odex file should not change!
# busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
now replace the old .odex file with the new .odex file.
# cd /system/framework
# busybox cp /sdcard/new.odex services.odex
# busybox chmod 644 services.odex
and you're done.
# sync
# reboot
Now, if all goes well, your phone should reboot normally.
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
software_samurai said:
Yeah, it took me a week of digging to find this answer.
Disclaimer:
1. Proceed at your own risk and don't blame me if you brick your phone.
2. While I've done my best to document the steps I took, there's always a chance I've mistyped something.
3. If you're unsure at any point, STOP! Re-read everything so you fully understand what you're doing.
4. Editing .odex files can be extremely tricky! All it takes is a bad edit to royally screw up your phone.
This guide assumes:
* you have a Captivate and it's running stock Eclair. (Don't know about other phones or other OSes.)
* you have rooted your phone, and have busybox & Superuser Permissions installed.
* you have adb installed and working on a PC.
* you have baksmali and smali installed and working on a PC (along with Java).
* you have downloaded the utility "dexopt-wrapper". (Do a search - you'll find it.)
* you know what the BOOTCLASSPATH value is for your phone. (Hint: It's in /init.rc)
* you have made a complete backup of your phone! (Yes, if something goes wrong, it's much nicer to be able to restore files from a recent backup than to have to wipe the phone and start from scratch again.)
- I highly recommend you install ROM Manager w/ ClockworkMod. (And don't delete /sdcard/update.zip)
Notations:
When you see a line beginning with >, that's a command to be executed on the PC.
When you see a line beginning with #, that's a command to be executed on the phone.
Ready? Here we go:
put the dexopt-wrapper onto your phone.
> adb push dexopt-wrapper /sdcard
copy all of the /system/framework files onto your PC.
> adb pull /system/framework
let's pretend you want to change something in services.odex.
decompile the .odex file
> baksmali -x services.odex -o services.out
now edit whatever .smali file you want in the services.out folder.
rebuild the classes.dex file for services.odex.
> smali -o classes.dex services.out
now put classes.dex into services.jar (I used WinRAR, but other ZIP utilities should work.)
put the new .jar file onto your phone.
> adb push services.jar /sdcard
> adb shell
become super user
# su
put the dexopt-wrapper utility into the bin folder with the correct permissions. (you only need to do this once, obviously.)
# cd /system/bin
# busybox cp /sdcard/dexopt-wrapper .
# busybox chmod 755 dexopt-wrapper
# cd /sdcard
create a new .odex file from the new .jar file
# dexopt-wrapper services.jar new.odex [BOOTCLASSPATH]
yes, fill in the value of BOOTCLASSPATH, without the []
here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
hint: the file size of the new.odex file should not change!
# busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
now replace the old .odex file with the new .odex file.
# cd /system/framework
# busybox cp /sdcard/new.odex services.odex
# busybox chmod 644 services.odex
and you're done.
# sync
# reboot
Now, if all goes well, your phone should reboot normally.
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
Click to expand...
Click to collapse
Thanks, was really useful for me
awsome thx
super thanks for guide
Strange... all thanks but nothing to add?
I had to install the new Android SDK r16 because of buggy "adb" executable (my fault).
http://developer.android.com/sdk/index.html
Newest version smali/baksmali v1.3.0 has been used.
Helpfull page:
http://code.google.com/p/smali/wiki/DeodexInstructions
Copied whole "/system/framework" to my current working folder (reason in command below).
Code:
baksmali -c /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar -a 10 -x Mms.odex -o Mms.out
Already had to put "BOOTCLASSPATH" in this command with "-c" option, else I would get an error stating. "Error occured while loading boot class path files.".
With new baksmali you have to put in the Android SDK api-level with option "-a" of the current Android OS you're working on. For Gingerbread numbers 10-13 work, but 14 (ICS) doesn't work anymore.
Api levels are stated right at the beginning on each "Android X.X Platform" links on the left side of Android SDK page (mentioned above).
For the most part this guide was perfect, but since a lot has been updated I felt this guide needed a minor update too!
to get quicker answers to non-captivate specific questions (without a week of searching) ask android software questions in the XDA > Android OS > fourms instead of the XDA>Captivate fourms.
the Captivate forums are not a frequent stop for experienced programmers and developers to find and answer these type of questions.
software_samurai said:
Yeah, it took me a week of digging to find this answer.
Disclaimer:
1. Proceed at your own risk and don't blame me if you brick your phone.
2. While I've done my best to document the steps I took, there's always a chance I've mistyped something.
3. If you're unsure at any point, STOP! Re-read everything so you fully understand what you're doing.
4. Editing .odex files can be extremely tricky! All it takes is a bad edit to royally screw up your phone.
This guide assumes:
* you have a Captivate and it's running stock Eclair. (Don't know about other phones or other OSes.)
* you have rooted your phone, and have busybox & Superuser Permissions installed.
* you have adb installed and working on a PC.
* you have baksmali and smali installed and working on a PC (along with Java).
* you have downloaded the utility "dexopt-wrapper". (Do a search - you'll find it.)
* you know what the BOOTCLASSPATH value is for your phone. (Hint: It's in /init.rc)
* you have made a complete backup of your phone! (Yes, if something goes wrong, it's much nicer to be able to restore files from a recent backup than to have to wipe the phone and start from scratch again.)
- I highly recommend you install ROM Manager w/ ClockworkMod. (And don't delete /sdcard/update.zip)
Notations:
When you see a line beginning with >, that's a command to be executed on the PC.
When you see a line beginning with #, that's a command to be executed on the phone.
Ready? Here we go:
put the dexopt-wrapper onto your phone.
> adb push dexopt-wrapper /sdcard
copy all of the /system/framework files onto your PC.
> adb pull /system/framework
let's pretend you want to change something in services.odex.
decompile the .odex file
> baksmali -x services.odex -o services.out
now edit whatever .smali file you want in the services.out folder.
rebuild the classes.dex file for services.odex.
> smali -o classes.dex services.out
now put classes.dex into services.jar (I used WinRAR, but other ZIP utilities should work.)
put the new .jar file onto your phone.
> adb push services.jar /sdcard
> adb shell
become super user
# su
put the dexopt-wrapper utility into the bin folder with the correct permissions. (you only need to do this once, obviously.)
# cd /system/bin
# busybox cp /sdcard/dexopt-wrapper .
# busybox chmod 755 dexopt-wrapper
# cd /sdcard
create a new .odex file from the new .jar file
# dexopt-wrapper services.jar new.odex [BOOTCLASSPATH]
yes, fill in the value of BOOTCLASSPATH, without the []
here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
hint: the file size of the new.odex file should not change!
# busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
now replace the old .odex file with the new .odex file.
# cd /system/framework
# busybox cp /sdcard/new.odex services.odex
# busybox chmod 644 services.odex
and you're done.
# sync
# reboot
Now, if all goes well, your phone should reboot normally.
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
Click to expand...
Click to collapse
excuse me, where to find the "dexopt_wrapper"? i can't find it anywhere!
Search with Google. You'll find it that way.
Daniel D. said:
Search with Google. You'll find it that way.
Click to expand...
Click to collapse
i found a dexopt in my /system/bin directory. 9.63k
is it the dexopt-wrapper i needed?
if it is, should i rename it to 'dexopter-wrapper' to use it?
software_samurai said:
Yeah, it took me a week of digging to find this answer.
Disclaimer:
1. Proceed at your own risk and don't blame me if you brick your phone.
2. While I've done my best to document the steps I took, there's always a chance I've mistyped something.
3. If you're unsure at any point, STOP! Re-read everything so you fully understand what you're doing.
4. Editing .odex files can be extremely tricky! All it takes is a bad edit to royally screw up your phone.
This guide assumes:
* you have a Captivate and it's running stock Eclair. (Don't know about other phones or other OSes.)
* you have rooted your phone, and have busybox & Superuser Permissions installed.
* you have adb installed and working on a PC.
* you have baksmali and smali installed and working on a PC (along with Java).
* you have downloaded the utility "dexopt-wrapper". (Do a search - you'll find it.)
* you know what the BOOTCLASSPATH value is for your phone. (Hint: It's in /init.rc)
* you have made a complete backup of your phone! (Yes, if something goes wrong, it's much nicer to be able to restore files from a recent backup than to have to wipe the phone and start from scratch again.)
- I highly recommend you install ROM Manager w/ ClockworkMod. (And don't delete /sdcard/update.zip)
Notations:
When you see a line beginning with >, that's a command to be executed on the PC.
When you see a line beginning with #, that's a command to be executed on the phone.
Ready? Here we go:
put the dexopt-wrapper onto your phone.
> adb push dexopt-wrapper /sdcard
copy all of the /system/framework files onto your PC.
> adb pull /system/framework
let's pretend you want to change something in services.odex.
decompile the .odex file
> baksmali -x services.odex -o services.out
now edit whatever .smali file you want in the services.out folder.
rebuild the classes.dex file for services.odex.
> smali -o classes.dex services.out
now put classes.dex into services.jar (I used WinRAR, but other ZIP utilities should work.)
put the new .jar file onto your phone.
> adb push services.jar /sdcard
> adb shell
become super user
# su
put the dexopt-wrapper utility into the bin folder with the correct permissions. (you only need to do this once, obviously.)
# cd /system/bin
# busybox cp /sdcard/dexopt-wrapper .
# busybox chmod 755 dexopt-wrapper
# cd /sdcard
create a new .odex file from the new .jar file
# dexopt-wrapper services.jar new.odex [BOOTCLASSPATH]
yes, fill in the value of BOOTCLASSPATH, without the []
here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
hint: the file size of the new.odex file should not change!
# busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
now replace the old .odex file with the new .odex file.
# cd /system/framework
# busybox cp /sdcard/new.odex services.odex
# busybox chmod 644 services.odex
and you're done.
# sync
# reboot
Now, if all goes well, your phone should reboot normally.
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
Click to expand...
Click to collapse
very well written guide for begginers, all other guides i tried were so confusing. thanks
software_samurai said:
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
Click to expand...
Click to collapse
If you backup the original services.odex before you replace it with the modified one then if you get stuck in a bootloop you can just use adb shell commands to copy it back and then do adb reboot. This worked for me anyways. Faster then doing a full restore.
Of course you should still to a backup beforehand.
For those of you who want delivery/read reports in SMS/MMS here is a simple CSC edit to enable them.
NOTE: If you are running KoolKit Roms you must edit /system/csc/koolkit.xml
connect your device to your PC, make sure you have adb tools installed and usb drivers installed
adb pull /system/csc/feature.xml
Make the following changes to your /system/csc/feature.xml
Search for the following lines:
Code:
<CscFeature_Message_DisableMenuRequestMmsReadReport>[COLOR="Red"]true[/COLOR]</CscFeature_Message_DisableMenuRequestMmsReadReport>
<CscFeature_Message_DisableMenuSmsDeliveryReports>[COLOR="Red"]true[/COLOR]</CscFeature_Message_DisableMenuSmsDeliveryReports>
<CscFeature_Message_DisableMenuRequestMmsDeliveryReport>[COLOR="Red"]true[/COLOR]</CscFeature_Message_DisableMenuRequestMmsDeliveryReport>
<CscFeature_Message_EnableMenuSendMmsDeliveryReport>[COLOR="Red"]false[/COLOR]</CscFeature_Message_EnableMenuSendMmsDeliveryReport>
Change the values highlighted in Red to the Values highlighted in Blue as seen below:
Code:
<CscFeature_Message_DisableMenuRequestMmsReadReport>[COLOR="Blue"]false[/COLOR]</CscFeature_Message_DisableMenuRequestMmsReadReport>
<CscFeature_Message_DisableMenuSmsDeliveryReports>[COLOR="Blue"]false[/COLOR]</CscFeature_Message_DisableMenuSmsDeliveryReports>
<CscFeature_Message_DisableMenuRequestMmsDeliveryReport>[COLOR="Blue"]false[/COLOR]</CscFeature_Message_DisableMenuRequestMmsDeliveryReport>
<CscFeature_Message_EnableMenuSendMmsDeliveryReport>[COLOR="Blue"]true[/COLOR]</CscFeature_Message_EnableMenuSendMmsDeliveryReport>
reboot to SafeStrap recovery and mount system read/write
adb push feature.xml /system/csc/feature.xml
adb shell
cd /system/csc
chmod 0644 feature.xml
Reboot, and enjoy delivery reports for SMS and read reports for MMS
DEVs, Feel free to include this in any rom or mod you build all i ask is proper mention in your thread
@cstayton
Another Great work Craig.[emoji41][emoji106]
any way to do this on stock lolipop (not rooted)?
puddi said:
any way to do this on stock lolipop (not rooted)?
Click to expand...
Click to collapse
Pull file edit. Then push file back set permission.
Hello everyone.
Let's get right to the point. I found TWRP Backup files of the STOCK ROM for HTC Desire 510 64-bit. When I restore them with TWRP it all goes great. But I don't always want to restore so I decided to make a flashable zip file. I extracted all the files from system.ext4.win000 and system.ext4.win001 and combined them in to one folder. Then I used this tool http://forum.xda-developers.com/showthread.php?t=2747279 to make my update-script. This is the part where I spent 4 hours to learn and fix errors in my script. But I finally did it :victory::victory: . But when I rebooted the phone, it just hanged and rebooted itself in to recovery mode :crying:
This is my update-script:
Code:
ui_print("HTC Sense 6 Android 4.4.3");
ui_print("Only for HTC Desire 510 64-bit");
show_progress(1.000000, 0);
ui_print("Mounting /system");
mount("ext4", "EMMC", "/dev/block/mmcblk1p21", "/system");
set_progress(0.200000);
ui_print("Extracting files to /system");
package_extract_dir("system", "/system");
set_progress(0.400000);
ui_print("Setting permissions");
set_perm_recursive(0,0,0755, 0644, "/system");
set_progress(0.500000);
ui_print("Please wait, boot.img being flashed...");
package_extract_file("boot.img", "/tmp/boot.img");
write_raw_image("/tmp/boot.img", "boot");
delete("/tmp/boot.img");
set_progress(0.600000);
ui_print("Boot image has been flashed");
set_progress(0.800000);
ui_print("Unmounting /system");
unmount("/system");
set_progress(0.900000);
ui_print("Update complete.");
set_progress(1.000000);
Could my permissions be wrong? Should I try with Philiz Touch Recovery? Or any other suggestion would be very grateful.
I just found out that the boot.img isn't being flashed properly, so after I flashed the ZIP I used fastboot to flash the boot.img manually but with no luck. It still reboots in to recovery.
I found out that the system is actually on /dev/block/mmcblk0p50. I tried this way but still nothing. I even tried with /dev/block/mmcblk1p50 but still no luck. Could the ROM be missing some files? Any help would be appreciated.
I read that it could be an update-binary problem. So I tried with different binaries but nothing. At this point I'm out of options.
denny.hell said:
I read that it could be an update-binary problem. So I tried with different binaries but nothing. At this point I'm out of options.
Click to expand...
Click to collapse
It's simply because you aren't s-off and dont have the correct permissions. However if you're looking for a stock 64 bit rom than I have one.
MrMike2182 said:
It's simply because you aren't s-off and dont have the correct permissions. However if you're looking for a stock 64 bit rom than I have one.
Click to expand...
Click to collapse
I don't think that this has anything to do with s-on/off. My bootloader is unlocked, I have TWRP. I have access to the system partition. I'm having trouble with programming the updater-script in the META-INF folder. I can't make it to flash properly.
But I think that I forgot to sign the ZIP archive. I have to try that.
I already have three stock backup files. I have one from the UK(don't know the operator), another one from Australian Telstra and from Romanian Orange. (I think that one of them is from you actually. I found it here on XDA) But thanks for offering it
This is a little off topic, but could I ask you for some help? It's about porting MIUI to this phone. I started it. I have everything set up. I made the first patch. And I've got rejects that I need to fix manually. I read two tutorials about rejects but I'm having trouble understanding them. Could you help me out here....give some guidelines....?
denny.hell said:
I don't think that this has anything to do with s-on/off. My bootloader is unlocked, I have TWRP. I have access to the system partition. I'm having trouble with programming the updater-script in the META-INF folder. I can't make it to flash properly.
But I think that I forgot to sign the ZIP archive. I have to try that.
I already have three stock backup files. I have one from the UK(don't know the operator), another one from Australian Telstra and from Romanian Orange. (I think that one of them is from you actually. I found it here on XDA) But thanks for offering it
This is a little off topic, but could I ask you for some help? It's about porting MIUI to this phone. I started it. I have everything set up. I made the first patch. And I've got rejects that I need to fix manually. I read two tutorials about rejects but I'm having trouble understanding them. Could you help me out here....give some guidelines....?
Click to expand...
Click to collapse
You still need s-off to access and write anything to those partitions you're talking about otherwise anything you try to write to them isn't going to work... Now about the rejects, which parts are you referring to that need manual fixing?
Also, how and what have you done to port or start working on the rom?
MrMike2182 said:
You still need s-off to access and write anything to those partitions you're talking about otherwise anything you try to write to them isn't going to work... Now about the rejects, which parts are you referring to that need manual fixing?
Also, how and what have you done to port or start working on the rom?
Click to expand...
Click to collapse
Thank you for putting an interest in this. I started out with this guide http://forum.xda-developers.com/android/software/guide-build-port-miui-rom-to-device-t3250984 I have the Stock ROM as a base rom. I followed it until the "make firstpatch" command. After this I got rejects that the PatchROM couldn't fix by it self so I have to fix them manually before I can build the rom. These are the folders with rejects: Screenshot . I have around 45 rejects scattered inside those folders. I read this http://forum.xda-developers.com/chef-central/android/guide-patchrom-rejects-fixing-tutorial-t3203287 and this http://www.markusbe.com/2009/12/how-to-read-a-patch-or-diff-and-understand-its-structure-to-apply-it-manually/ reject guides but I'm having trouble understanding them.
About the other thing....If I don't have access to the system partition then how am I able to flash CyanogenMod 12.1 from Patrik?
denny.hell said:
Thank you for putting an interest in this. I started out with this guide http://forum.xda-developers.com/android/software/guide-build-port-miui-rom-to-device-t3250984 I have the Stock ROM as a base rom. I followed it until the "make firstpatch" command. After this I got rejects that the PatchROM couldn't fix by it self so I have to fix them manually before I can build the rom. These are the folders with rejects: Screenshot . I have around 45 rejects scattered inside those folders. I read this http://forum.xda-developers.com/chef-central/android/guide-patchrom-rejects-fixing-tutorial-t3203287 and this http://www.markusbe.com/2009/12/how-to-read-a-patch-or-diff-and-understand-its-structure-to-apply-it-manually/ reject guides but I'm having trouble understanding them.
About the other thing....If I don't have access to the system partition then how am I able to flash CyanogenMod 12.1 from Patrik?
Click to expand...
Click to collapse
I didn't mean you have NO access to all partitions. What I mean is there's partitions on there that you're not even capable of seeing because you're not s-off and can't access them. If you were s-off and opened a file explorer you'd see a bunch of other partitions that you never knew were there. Regarding the rejects you really have to set the build environment up 100% correctly otherwise it's just not going to work.. First it has to basically create every single file/folder/apk it needs before it will ever even compile it into a .zip flashable format.. That can take hours depending on your system... You're basically trying to do the same thing us devs do when we're building CM, just your trying to do MIUI instead..
Yes I know that it has to be 100% correct. It was all in the tutorial. I also know that it could take hours too. But first i have to fix those rejects. But I have no idea where to start with the fixing. I read the tutorials above and I can only understand the basic terminology. What I want to now is how to fix them....How to know what reject is for what. And surprisingly in those tutorials they never mention which file I should edit. The .rej file or the original file. I'm really confused with all that stuff.
I'm s-on and I can still see all of the partitions. I can't access them but I know they are there. My problem is flashing the system partition using TWRP. I'm gonna try tommorow to sign the ZIP before I flash it. Maybe that will do the trick.
denny.hell said:
I'm s-on and I can still see all of the partitions. I can't access them but I know they are there. My problem is flashing the system partition using TWRP. I'm gonna try tommorow to sign the ZIP before I flash it. Maybe that will do the trick.
Click to expand...
Click to collapse
Post the output of some of your errors/rejects so I can have a look at it.
MrMike2182 said:
Post the output of some of your errors/rejects so I can have a look at it.
Click to expand...
Click to collapse
Code:
*** UsbDeviceManager.smali 2016-02-29 02:52:29.596546250 +0100
--- UsbDeviceManager.smali 2016-02-29 02:58:30.861463482 +0100
***************
*** 196,234 ****
invoke-direct {p0}, Lcom/android/server/usb/UsbDeviceManager;->startAccessoryMode()V
:cond_0
- const-string v3, "ro.adb.secure"
-
- const/4 v4, 0x0
-
- invoke-static {v3, v4}, Landroid/os/SystemProperties;->getBoolean(Ljava/lang/String;Z)Z
-
- move-result v2
-
- .local v2, "secureAdbEnabled":Z
- const-string v3, "1"
-
- const-string v4, "vold.decrypt"
-
- invoke-static {v4}, Landroid/os/SystemProperties;->get(Ljava/lang/String;)Ljava/lang/String;
-
- move-result-object v4
-
- invoke-virtual {v3, v4}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z
-
- move-result v0
-
- .local v0, "dataEncrypted":Z
- if-eqz v2, :cond_1
-
- if-nez v0, :cond_1
-
- new-instance v3, Lcom/android/server/usb/UsbDebuggingManager;
-
- invoke-direct {v3, p1}, Lcom/android/server/usb/UsbDebuggingManager;-><init>(Landroid/content/Context;)V
-
- iput-object v3, p0, Lcom/android/server/usb/UsbDeviceManager;->mDebuggingManager:Lcom/android/server/usb/UsbDebuggingManager;
-
- :cond_1
return-void
.end method
--- 196,201 ----
invoke-direct {p0}, Lcom/android/server/usb/UsbDeviceManager;->startAccessoryMode()V
:cond_0
return-void
.end method
***************
*** 1307,1333 ****
.end method
.method public clearUsbDebuggingKeys()V
! .locals 2
.prologue
- iget-object v0, p0, Lcom/android/server/usb/UsbDeviceManager;->mDebuggingManager:Lcom/android/server/usb/UsbDebuggingManager;
-
- if-eqz v0, :cond_0
-
- iget-object v0, p0, Lcom/android/server/usb/UsbDeviceManager;->mDebuggingManager:Lcom/android/server/usb/UsbDebuggingManager;
-
- invoke-virtual {v0}, Lcom/android/server/usb/UsbDebuggingManager;->clearUsbDebuggingKeys()V
-
return-void
-
- :cond_0
- new-instance v0, Ljava/lang/RuntimeException;
-
- const-string v1, "Cannot clear Usb Debugging keys, UsbDebuggingManager not enabled"
-
- invoke-direct {v0, v1}, Ljava/lang/RuntimeException;-><init>(Ljava/lang/String;)V
-
- throw v0
.end method
.method public denyUsbDebugging()V
--- 1274,1283 ----
.end method
.method public clearUsbDebuggingKeys()V
! .locals 0
.prologue
return-void
.end method
.method public denyUsbDebugging()V
This is from /home/denny/htc_a11ul/temp/reject/services.jar.out/smali/com/android/server/usb/UsbDeviceManager.smali.rej
https://mega.nz/#!rJ4nDQBC this is the original file. It's too long to posted here. This is the decryption key: !bwcAZTgPWVEWQ7SLzhlgsIcwZ0Kuy8ob2esGpZa8QmU
It looks to me like you need to enable debugging because that's what it's saying and then right down at the bottom it says deny..
MrMike2182 said:
It looks to me like you need to enable debugging because that's what it's saying and then right down at the bottom it says deny..
Click to expand...
Click to collapse
I don't think that we understand each other well but never mind I reread the reject tutorial a couple of more times. I think I understood it The "-" sign at the beginning of each line means that I need to find those line in the original smali file and delete them. I've fixed almost all of the rejects and than I made another patch to see If I fixed them. And now it give me a double amount of rejects. I already posted in the original guide thread to see if someone there could explain me why I got double amount of rejects. I'm also going to open a thread on our forums about my idea and maybe someone here could help me out. Anyway, thank you for helping me and pushing me to move forward with this idea. I hope someday I can accomplish it
Hello,
NFC does not work when the screen is off or locked. XlAfbk has explained the steps to follow in order to make the NFC working with the screen locked. This is working very well on my Note 8 (SM-N9500) with Android 8.0 (does not break SafetyNet and works with NFC payments). The steps:
1. Pull NfcNci.apk from your device: adb pull /system/app/NfcNci/NfcNci.apk
2. Download smali-<version>.jar and baksmali-<version>.jar from https://bitbucket.org/JesusFreke/smali/downloads
3. Put NfcNci.apk and the 2 .jar files in the same directory
4. open a command prompt in that directory
5. open NfcNci.apk with 7z/winzip/winrar/... and extract classes.dex from it (into the same directory)
6. run: java -jar baksmali-<version>.jar classes.dex -o out
7. navigate to directory out\com\android\nfc
8. open NfcService.smali in a text editor
9. search for "android.intent.action.SCREEN_OFF" and replace with "android.intent.action.SCREEN_OFFA"
10. search for "android.intent.action.SCREEN_ON" and replace with "android.intent.action.SCREEN_ONA"
11. search for "android.intent.action.USER_PRESENT" and replace with "android.intent.action.USER_PRESENTA"
12. search for "android.intent.action.USER_SWITCHED" and replace with "android.intent.action.USER_SWITCHEDA"
13. search for ".method private computeDiscoveryParameters" -> about 20 lines below it should be a line like "if-lt v2, p1, :cond_5b" -> replace the 2 parameters in that function (in this example: "if-lt p1, v2, :cond_5b")
14. open ScreenStateHelper.smali in a text editor
15. search for ".method checkScreenState()I" -> change all the return values ("const/4 v0, 0x...") to "const/4 v0, 0x3"
16. run: java -jar smali-<version>.jar out -o classes.dex
17. open NfcNci.apk with 7z/winzip/winrar/... and add classes.dex to it
18. push the modded apk to your device: adb push NfcNci.apk /system/app/NfcNci/NfcNci.apk. Do not forget to make a backup of the original NfcNci.apk before.
19. chmod 644 /system/app/NfcNci/NfcNci.apk
All credit goes to the original writer of the guides: https://forum.xda-developers.com/xposed/modules/mod-nfc-unlocking-based-t2478163/post59941326
Alternately, you can download the modded NfcNci.apk and install it with adb. This is for the Note 8 (SM-N9500) with Android 8.0. It might work for other versions of Note 8.
Nice. I'm guessing root is required?
Yes. Root is required.
oddbehreif said:
Nice. I'm guessing root is required?
Click to expand...
Click to collapse
LeBobbo said:
Hello,
NFC does not work when the screen is off or locked. XlAfbk has explained the steps to follow in order to make the NFC working with the screen locked. This is working very well on my Note 8 (SM-N9500) with Android 8.0 (does not break SafetyNet and works with NFC payments). The steps:
1. Pull NfcNci.apk from your device: adb pull /system/app/NfcNci/NfcNci.apk
2. Download smali-<version>.jar and baksmali-<version>.jar from https://bitbucket.org/JesusFreke/smali/downloads
3. Put NfcNci.apk and the 2 .jar files in the same directory
4. open a command prompt in that directory
5. open NfcNci.apk with 7z/winzip/winrar/... and extract classes.dex from it (into the same directory)
6. run: java -jar baksmali-<version>.jar classes.dex -o out
7. navigate to directory out\com\android\nfc
8. open NfcService.smali in a text editor
9. search for "android.intent.action.SCREEN_OFF" and replace with "android.intent.action.SCREEN_OFFA"
10. search for "android.intent.action.SCREEN_ON" and replace with "android.intent.action.SCREEN_ONA"
11. search for "android.intent.action.USER_PRESENT" and replace with "android.intent.action.USER_PRESENTA"
12. search for "android.intent.action.USER_SWITCHED" and replace with "android.intent.action.USER_SWITCHEDA"
13. search for ".method private computeDiscoveryParameters" -> about 20 lines below it should be a line like "if-lt v2, p1, :cond_5b" -> replace the 2 parameters in that function (in this example: "if-lt p1, v2, :cond_5b")
14. open ScreenStateHelper.smali in a text editor
15. search for ".method checkScreenState()I" -> change all the return values ("const/4 v0, 0x...") to "const/4 v0, 0x3"
16. run: java -jar smali-<version>.jar out -o classes.dex
17. open NfcNci.apk with 7z/winzip/winrar/... and add classes.dex to it
18. push the modded apk to your device: adb push NfcNci.apk /system/app/NfcNci/NfcNci.apk. Do not forget to make a backup of the original NfcNci.apk before.
19. chmod 644 /system/app/NfcNci/NfcNci.apk
All credit goes to the original writer of the guides: https://forum.xda-developers.com/xposed/modules/mod-nfc-unlocking-based-t2478163/post59941326
Alternately, you can download the modded NfcNci.apk and install it with adb. This is for the Note 8 (SM-N9500) with Android 8.0. It might work for other versions of Note 8.
Click to expand...
Click to collapse
Have you upgraded to pie, and does this mod still work? I'm not on a Samsung device but want to make the mods myself, just wondering if anything has changed from oreo to pie