Hi Fellow devs,
As you may know, I have been compiling Android 4.0-4.3-based ROMs for Galaxy Tab 10.1. Currently, I am trying to get kitkat 4.4 to work on our devices.
Although I can compile a ROM with only minor difficulties, it already fails when flashing a ROM. It errors with the following message: "set_metadata_recursive: some changes failed". I think this is related to the new way of setting permissions in KK4.4.
If I look in the recovery.log after flashing, I see this:
minzip: Extracted 1197 file(s)
ApplyParsedPerms: removexattr of /system/addon.d/50-hosts.sh to 0 failed: Operation not supported on transport endpoint
script aborted: set_metadata_recursive: some changes failed
set_metadata_recursive: some changes failed
E:Error executing updater binary in zip
I have no idea whether the problem is that the recovery needs an update, or the updater binary is not yet finished, or that the updater script needs to be adjusted.
Anyone also working on this?
Hello, although I'm not a rom dev, I think I found the problem and a possible solution.
http://forum.xda-developers.com/showthread.php?p=47212560#post47212560
Here, I hope it's of some use to you. Keep up the good, quality work!
miztahbeezy said:
Hello, although I'm not a rom dev, I think I found the problem and a possible solution.
http://forum.xda-developers.com/showthread.php?p=47212560#post47212560
Here, I hope it's of some use to you. Keep up the good, quality work!
Click to expand...
Click to collapse
Thanks. I guess it is related to recovery then, with a need for an updated recovery. I guess that the lack of proper selinux support may also contribute to the problem....
OK, I tried to build both cwm & twrp based on latest kk source code. Recovery image is always over 5.5MB, which is way too large for our device, as our recovery partition is only 5MB. Even when trying to strip recovery & recompile kernel with maximum compression, I can't get to 5MB.
So then I tried a different route, I put the old permission code from an updater-script from jb4.3 in a kk4.4 ROM. Flashing such a ROM works, but it hangs on the bootanimation. Logcat won't connect, so I couldn't find the source of the problem.
Verstuurd van mijn Nexus 5
Go Kasper! ben trots op je! (proud of you!)
kasper_h said:
OK, I tried to build both cwm & twrp based on latest kk source code. Recovery image is always over 5.5MB, which is way too large for our device, as our recovery partition is only 5MB. Even when trying to strip recovery & recompile kernel with maximum compression, I can't get to 5MB.
So then I tried a different route, I put the old permission code from an updater-script from jb4.3 in a kk4.4 ROM. Flashing such a ROM works, but it hangs on the bootanimation. Logcat won't connect, so I couldn't find the source of the problem.
Verstuurd van mijn Nexus 5
Click to expand...
Click to collapse
kasper_h said:
Hi Fellow devs,
As you may know, I have been compiling Android 4.0-4.3-based ROMs for Galaxy Tab 10.1. Currently, I am trying to get kitkat 4.4 to work on our devices.
Although I can compile a ROM with only minor difficulties, it already fails when flashing a ROM. It errors with the following message: "set_metadata_recursive: some changes failed". I think this is related to the new way of setting permissions in KK4.4.
If I look in the recovery.log after flashing, I see this:
minzip: Extracted 1197 file(s)
ApplyParsedPerms: removexattr of /system/addon.d/50-hosts.sh to 0 failed: Operation not supported on transport endpoint
script aborted: set_metadata_recursive: some changes failed
set_metadata_recursive: some changes failed
E:Error executing updater binary in zip
I have no idea whether the problem is that the recovery needs an update, or the updater binary is not yet finished, or that the updater script needs to be adjusted.
Anyone also working on this?
Click to expand...
Click to collapse
Just sent a message to pershoot on gtalk or whatever its supposed to be called, I'll let you know if he says he'll take a look at it
update: he's hasn't been working on the sgt 10.1 in a long time, but if he get's some free time, he might look at it.
good luck either way, you seem to have no trouble pumping out good stuff, I'm sure you'll get it figured out
I'm no developer, but I did some Google search about the error. Most people said that latest recovery is needed, but there's another guy with a different point of view: http://stackoverflow.com/questions/19860479/set-metadata-recursive-failing-on-android-install
Good luck getting KitKat to boot on our tabs!
Sent from my GT-P7500 using Tapatalk HD
eushaun99 said:
I'm no developer, but I did some Google search about the error. Most people said that latest recovery is needed, but there's another guy with a different point of view: http://stackoverflow.com/questions/19860479/set-metadata-recursive-failing-on-android-install
Good luck getting KitKat to boot on our tabs!
Sent from my GT-P7500 using Tapatalk HD
Click to expand...
Click to collapse
Thanks, any help is appreciated!
I actually got recovery to shrink enough to fit in the recovery partition. It just won't boot
The struggle continues
Well then let's just hope that pershoot finds some time to help us out.
Sent from my GT-P7500 using Tapatalk HD
kasper_h said:
Thanks, any help is appreciated!
I actually got recovery to shrink enough to fit in the recovery partition. It just won't boot
The struggle continues
Click to expand...
Click to collapse
Could you please share the recovery?
I found this thing ro.build.selinux=1 in the build.prop. Is there someway to change this to 0 and removing all the set_metadata_recursive lines from the updater-script? Doesn't work
Here's what I've tried so far: I followed my android 4.3 guide but it needs some extras. There's 1 header line from libnbaio/audiostreamoutsink that needs to be removed. The error message tells you exactly which one. I also had to comment out 2 lines in surfaceflinger to prevent a very annoying crash I got when I first did android 4.3. There are a few other random lines from audioflinger that have to be removed but the error messages are pretty specific on which ones those are. I also cheated the recovery's gr_text that it said was missing and added in a dummy function according to the header since I never planned to use the recovery and just put that in to get it to compile. I can't get past a metadata error in cwm recovery from pershoot. My TWRP refuses to install the zip at all.
AAccount said:
Could you please share the recovery?
I found this thing ro.build.selinux=1 in the build.prop. Is there someway to change this to 0 and removing all the set_metadata_recursive lines from the updater-script? Doesn't work
Here's what I've tried so far: I followed my android 4.3 guide but it needs some extras. There's 1 header line from libnbaio/audiostreamoutsink that needs to be removed. The error message tells you exactly which one. I also had to comment out 2 lines in surfaceflinger to prevent a very annoying crash I got when I first did android 4.3. There are a few other random lines from audioflinger that have to be removed but the error messages are pretty specific on which ones those are. I also cheated the recovery's gr_text that it said was missing and added in a dummy function according to the header since I never planned to use the recovery and just put that in to get it to compile. I can't get past a metadata error in cwm recovery from pershoot. My TWRP refuses to install the zip at all.
Click to expand...
Click to collapse
Hi AAccount, thanks for joining in! I also talked to matt604 through gtalk last night. Glad to see I am not alone
I am trying to compile OMNI in stead of CM. Advantage is that it does not require any changes to the source code to compile for p4wifi. Works fine for 4.3 as well.
Anyway. I think we have two options: give proper SELinux support, which means making a SE policy for our device. Or we have to completely get rid of it. Because I think the second is simpler, I chose that route. What I did:
-Add the ro.boot.selinux=disabled prop (maybe we should try ro.build.selinux=0 as well!)
-I removed all the SELinux patches from the kernel (so essentially go back to the 4.2 kernel). This kernel boot fine on 4.3
-Manually swap the set_metadata lines in the updater script by set_perm lines from a 4.3 script (I compared the two and besides the change from set_prop to set_metadata, the permissions set are the same).
This time the ROM booted. But when I saw the launcher for 0.1 sec, I got a "Launcher3 has unexpectedly stopped" error. And with the current security feature for adb, you can't get a logcat on a fresh ROM boot, as you need to approve the connection first, which is impossible due to the continuous FC.
I then also tried adding Apex Launcher (confirmed working on KK on my Nexus 5) - first added to system/app and then moved to /data/app. Both times didn't boot at all.
Removed Launcher3 with Apex in /system/app. Didn't boot.
But at least I saw kitkat running for 0.1sec on my tab, so I feel it should be possible!
My next step:
-Add the HAVE_SELINUX := false flags to BoardConfigCommon
-Add ro.build.selinux=0 to p4-common.mk
Samsung have updated their several devices which latest firmware of Android which are old but popular as new. Now the devices are on an end of its update life cycle on Jelly Bean. But the upcoming Google's Android 4.4 KitKat rise an hope for the older Galaxy phone as the KitKat is rumored to feature an improved Linux kernel supporting lower memory devices.
Here is the list of nominated Galaxy Devices for Android 4.4 KitKat
Galaxy Grand and Grand DUOS
Galaxy Ace II
Galaxy S III mini
Galaxy Beam
Galaxy Express
Galaxy S Advance
Galaxy S II and S II Plus
Galaxy Premier
Galaxy Note I
Galaxy Young and Young DUOS
Galaxy Fame
Galaxy X Cover 2
Galaxy Tabs
Click to expand...
Click to collapse
I think it's a little obious that our revoceries are not compatible anymore with android 4.4 since there changed alot in recoveries... So.. Older versions of CWM won’t work, nor will TWRP. I think we will need at least cwm 6.0.4.3 to be compatible with kitkat 4.4, our latest recovery is and older build (cwm 6.0.3.6) which is ment to be for android 4.2.2
Edit:
Looks like it's also because of selinux, and you need a newer version of TWRP or cwm as i said. Right now in the Omni 4.4 manifest it actually has the AOSP recovery so you'll wanna change that to Omni 's TWRP on a local manifest. Or at least you need a recovery with proper fstab because the new fstab format in Android 4.3+ is not used by TWRP yet. Beyond that it depends on your BoardConfig.mk whether the recovery is flash able, if you configured it ok then yes!
kasper_h said:
Hi AAccount, thanks for joining in! I also talked to matt604 through gtalk last night. Glad to see I am not alone
I am trying to compile OMNI in stead of CM. Advantage is that it does not require any changes to the source code to compile for p4wifi. Works fine for 4.3 as well.
Anyway. I think we have two options: give proper SELinux support, which means making a SE policy for our device. Or we have to completely get rid of it. Because I think the second is simpler, I chose that route. What I did:
-Add the ro.boot.selinux=disabled prop (maybe we should try ro.build.selinux=0 as well!)
-I removed all the SELinux patches from the kernel (so essentially go back to the 4.2 kernel). This kernel boot fine on 4.3
-Manually swap the set_metadata lines in the updater script by set_perm lines from a 4.3 script (I compared the two and besides the change from set_prop to set_metadata, the permissions set are the same).
This time the ROM booted. But when I saw the launcher for 0.1 sec, I got a "Launcher3 has unexpectedly stopped" error. And with the current security feature for adb, you can't get a logcat on a fresh ROM boot, as you need to approve the connection first, which is impossible due to the continuous FC.
I then also tried adding Apex Launcher (confirmed working on KK on my Nexus 5) - first added to system/app and then moved to /data/app. Both times didn't boot at all.
Removed Launcher3 with Apex in /system/app. Didn't boot.
But at least I saw kitkat running for 0.1sec on my tab, so I feel it should be possible!
My next step:
-Add the HAVE_SELINUX := false flags to BoardConfigCommon
-Add ro.build.selinux=0 to p4-common.mk
Click to expand...
Click to collapse
Perhaps this might be useful to you:
http://forum.xda-developers.com/showthread.php?t=2457427
Its a sort of work around to pre authorise the ADB connection to your computer using the ADB authentication keys from a working (i.e. 4.3 ROM) build.
It sounds like a very long work around though. Also don't want to sound insulting but did you remembered to put the appropriate mount and install lines for Apex while in /data/app into the updater script!
scaryshark said:
Perhaps this might be useful to you:
http://forum.xda-developers.com/showthread.php?t=2457427
Its a sort of work around to pre authorise the ADB connection to your computer using the ADB authentication keys from a working (i.e. 4.3 ROM) build.
It sounds like a very long work around though. Also don't want to sound insulting but did you remembered to put the appropriate mount and install lines for Apex while in /data/app into the updater script!
Click to expand...
Click to collapse
Thanks.
Don't worry, I am not easily insulted I even checked through a file manager whether apex ended up in the right spot. I didn't check permission though, so that may have been wrong, but I am almost sure I checked that one well...
Thanks kasper_h for your hard work. I thought HAVE_SELINUX boardconfig flag was only for android 4.2. I read that here http://selinuxproject.org/page/SEAndroid#Merge_Status. Another thing i t tried was changing the ro.selinux flag in 4.3.1 to see if it made any difference in the about device selinux status page. Setting that flag to disabled or 0 didn't effect that. Ill try omni rom next but i have limited time this weekend though. I agree a removal would be ideal. I disable it on my desktop and laptop right away after installing fedora.
Sent from my GT-P7510 using xda app-developers app
I now managed to get it to boot. But I get fatal errors in AUDIO_SERVICE, crashing the system. I had something similar when trying to compile AOSP in the past. Maybe CM11 is a better choice than OMNI...
I'll keep on trying.
But at least, getting rid of SELinux seems to be thé way to go.
So the xda app messed up my post big time. What I wanted to say was that by using a non selinux kernel, setting the selinux build.prop flag and changing the install script it boots? Yesterday I tried doing the build.prop edit on my cm11 rom and it didn't boot. Very interesting suggestion about the kernel though.
--------------------------------------------Added-----------------------------------------------------------------------
I tried the 3 things you did on my cm11 rom from yesterday:
-Add the ro.boot.selinux=disabled prop (maybe we should try ro.build.selinux=0 as well!)
-I removed all the SELinux patches from the kernel (so essentially go back to the 4.2 kernel). This kernel boot fine on 4.3
-Manually swap the set_metadata lines in the updater script by set_perm lines from a 4.3 script (I compared the two and besides the change from set_prop to set_metadata, the permissions set are the same).
and I can't get past the "samsung galaxy tab 10.1" screen. Note I did these things after the rom was compiled since build.prop can be edited from the update zip and I just flashed an older A1 kernel with no selinux.
kasper_h said:
I now managed to get it to boot. But I get fatal errors in AUDIO_SERVICE, crashing the system. I had something similar when trying to compile AOSP in the past. Maybe CM11 is a better choice than OMNI...
I'll keep on trying.
But at least, getting rid of SELinux seems to be thé way to go.
Click to expand...
Click to collapse
Finally downloaded the omnirom source. A possible cause of this is becasue omni rom has no ICS_AUDIO_BLOB flag in its source at all. You'll probably need to take a working android 4.3 source, do a "grep ICS_AUDIO_BLOB -r ." on the source and find every place in the working source this flag is defined and then transfer it over to omni rom. Yes it sounds like a pain in the butt.
AAccount said:
Finally downloaded the omnirom source. A possible cause of this is becasue omni rom has no ICS_AUDIO_BLOB flag in its source at all. You'll probably need to take a working android 4.3 source, do a "grep ICS_AUDIO_BLOB -r ." on the source and find every place in the working source this flag is defined and then transfer it over to omni rom. Yes it sounds like a pain in the butt.
Click to expand...
Click to collapse
Maybe it is easier to swap all OMNI project that contain ICS_AUDIO_BLOB in CM for the CM-code
With regard to the kernel, you can't flash a 4.2 kernel on 4.4, as there are ramdisk changes causing it to not boot. I can send you a kernel that will boot on 4.4 that you could try to flash on top of CM11....
I will try a kernel on CM11 and then compare the ramdisk to OMNI to see if that gives a hint why it won't boot...
kasper_h said:
Maybe it is easier to swap all OMNI project that contain ICS_AUDIO_BLOB in CM for the CM-code
With regard to the kernel, you can't flash a 4.2 kernel on 4.4, as there are ramdisk changes causing it to not boot. I can send you a kernel that will boot on 4.4 that you could try to flash on top of CM11....
I will try a kernel on CM11 and then compare the ramdisk to OMNI to see if that gives a hint why it won't boot...
Click to expand...
Click to collapse
What are those ramdisk changes? That would probably help for the rom not booting.
Related
I am not responsible for any possible bad effects which may result from using included software! You flash it on your own risk!!!
STOCK RELOADED v1 fix 1
Kernel base: stock XXUANC3 (kernel 3.4.0-1131235)
Kernel ramdisk: modded
Features: a few...
Security level: low!
Purpose: giving everyone who loves free exploring of Android secrets and who doesn't consider security as an absolute priority and who wants to put some life in this, indeed, awesome device, a possibility of playing with his device without disturbing restrictions, forced by Samsung, at least until fully-custom kernels, compiled from sources, appear (and that may take some time, as source code available atm seems to be broken, causing all the compiled kernels to stuck at boot screen).
Features working out-of-the-box:
- su binary from SuperSU by Chainfire @ /sbin/su (binary only for scripting purposes! Flash cf-root to use SuperSU app!)
- busybox 1.22.1 binary compiled by Stericson @ /sbin/busybox
- init.d support - just put your favorite scripts into /system/etc/init.d using any file manager and chmod 755 (not 777! it's NOT smart to permit write access for "world" to any system file), chown root:root, they will run on every boot. Well, to be honest, above permissions are given to all the scripts automatically during boot, but it has not yet been tested
- SELinux: Permissive - Samsung's most recent policy of forcing SELinux Enforcing mode by pre-compiling it into a kernel binary part, found in latest KitKat builds since at least a few months, HACKED FOR THE FIRST TIME EVER using innovative method of injecting an information directly into kernel memory space and forcing overwriting potentially-persistent kernel symbol value on-line during boot!)
- unsecure adb access (not tested yet)
- ext4 tweak: 20 sec (instead of stock 5 sec) write commit delay for /data partition (significantly increases IO performance!)
- some further, minor modifications
WARNING!!!
- flashing this WILL undoubtly trip KNOX, avoiding your warranty (which atm cannot be reverted! in any way)
- flashing this WILL cause a warning message of avoided warranty to be displayed on every boot (ofc it disappears right after reverting to stock boot.img)
- flashing this WILL disable some of the very important security features provided with stock firmware!!!! For advanced and experienced users only!!! Use at your own risk!
Known issues:
- AllCast Share mirroring not working (typical for all Samsung devices running not-exactly-stock kernels since S3). WORKING FIX AT POST #16!!!
http://forum.xda-developers.com/showpost.php?p=54516532&postcount=16
Please consider solution from post #3 as not-always-working and depreciated!
Installation:
- compatibile with XXUANC3 firmwares but probably also with other (past and hope future too...) KitKat 4.4.2 Samsung branded firmwares;
- rooting by Chainfire's CF-Root first recommended as it will install SuperSU app in Android (this kernel contains su binary only giving su access without any policy settings!);
- enter download mode and plug the tablet via USB...
- ...select provided file in PDA section (and NOT touch anything except that)...
- ...and flash with Odin in a same way as CF-Root or like anything else...
- enjoy.
DOWNLOAD HERE:
Current version - STOCK RELOADED v1 fix 1
http://www63.zippyshare.com/v/87557346/file.html
FIXED: file name changed so it can be flashed directly by Odin without renaming! Sorry for this silly mistake!
=======
Changelog:
v1 fix1:
- fixed permissive mode due to trivial error;
- delayed init.d execution to a moment AFTER init process set cfq scheduler so it is not overriding mmcblk0 tweaks (if put in init.d) anymore;
- minor code cleanups
v1:
- initial release
- init.d support
- SELinux permissive
- unsecure ADB
- ext4 delayed commit for /data
=======
Stock XXUANC3 kernel (to revert changes)
http://www65.zippyshare.com/v/32441894/file.html
Revert using Odin, in the same way you've installed a Reloaded Version....
Awww man,...I wish i could flash this, but I'm on the exynos =(
Sent from my SM-P900 using Tapatalk
rgolnazarian said:
Awww man,...I wish i could flash this, but I'm on the exynos =(
Sent from my SM-P900 using Tapatalk
Click to expand...
Click to collapse
Sorry pal, Qualcomm only, not even a chance to run this same way as the devices (and mostly important: provided software, ie. system structure) DIFFER A LOT between themselves.
Update 1: uploaded fix #1 which is resolving some trivial issues found in initial version; sorry for that, now we can say that every described feature has been included hope for some feedback... thank you...
Update 2: FIX FOR NOT WORKING SCREEN MIRRORING CAN BE DOWNLOADED HERE:
http://www67.zippyshare.com/v/25492738/file.html
I have personally modified a library that is being used by screen mirroring feature, which forces video encryption using keys from stock kernel, and which prevents to run mirroring at all . This is an issue of any modified kernel, on any Samsung device. Attached library fixes this, by disabling HDCP at all. It has been reported that the library resolves the issue for any Qualcomm based Samsung device running 4.4.2 KitKat and for any custom kernel. It will NOT work for Exynos devices...
Installation:
- download attached libwfdsm.so file
- overwrite genuine one in/system/vendor/lib (important! NOT /system/lib!!!!)
- chmod 644 libwfdsm.so ||| chown 0.0 libwfdsm.so ||| restorecon -R /system/vendor/lib
- mirroring will work again after reboot!!
YAY!
Beautiful, absolutely beautiful. You made ma a very happy man with this. I'll flash this as soon as I get home from work. Can't wait to try it out, the stock kernel is giving me SOD and frozen wifi issues sometimes.
esgie said:
Sorry pal, Qualcomm only, not even a chance to run this same way as the devices (and mostly important: provided software, ie. system structure) DIFFER A LOT between themselves.
Update 1: uploaded fix #1 which is resolving some trivial issues found in initial version; sorry for that, now we can say that every described feature has been included hope for some feedback... thank you...
Update 2: FIX FOR NOT WORKING SCREEN MIRRORING CAN BE DOWNLOADED HERE:
http://www67.zippyshare.com/v/25492738/file.html
I have personally modified a library that is being used by screen mirroring feature, which forces video encryption using keys from stock kernel, and which prevents to run mirroring at all . This is an issue of any modified kernel, on any Samsung device. Attached library fixes this, by disabling HDCP at all. It has been reported that the library resolves the issue for any Qualcomm based Samsung device running 4.4.2 KitKat and for any custom kernel. It will NOT work for Exynos devices...
Installation:
- download attached libwfdsm.so file
- overwrite genuine one in/system/vendor/lib (important! NOT /system/lib!!!!)
- chmod 644 libwfdsm.so ||| chown 0.0 libwfdsm.so ||| restorecon -R /system/vendor/lib
- mirroring will work again after reboot!!
Click to expand...
Click to collapse
I was literally just about to post in the old thread with bad news about the modified "libwfdsm.so" file & screen mirroring with a custom kernel...if u remember i confirmed that the file u altered would work with a custom recovery on the 8.4 lte & i just assumed that it would work with an altered boot.img as well but unfortunately thats not the case after testing the other night (unless something else is wrong with my setup). So...my question is have u changed something else since then to allow it to work again & have u personally tested this yourself?
sorry to hijack the thread...didnt know if i should pm or post in the older thread
THEDEVIOUS1 said:
I was literally just about to post in the old thread with bad news about the modified "libwfdsm.so" file & screen mirroring with a custom kernel...if u remember i confirmed that the file u altered would work with a custom recovery on the 8.4 lte & i just assumed that it would work with an altered boot.img as well but unfortunately thats not the case after testing the other night (unless something else is wrong with my setup). So...my question is have u changed something else since then to allow it to work again & have u personally tested this yourself?
sorry to hijack the thread...didnt know if i should pm or post in the older thread
Click to expand...
Click to collapse
No problem, anyway, thanks for pointing the issue out! This may be an important information for mirroring users!
Since then I didn't change anything, yet. Really, I am also not sure if I have tested it with modified kernel, as the one posted here is the first kernel for P905 at all, and it's not even "fully" customized, as the kernel binary base was left unchanged.
So, I'd like to be sure: you are saying that modded lib:
- fixed the problem for custom recovery, but...
- ...didn't fix it for custom kernel
right?
I was looking for a solution to persistent enforcing mode since some time, so I was flashing test boot.imgs from time to time, then reverting to stock again, meanwhile I created above lib, I can't really be sure about if it is working when both bootimg and kernel are customized (this would also be an opposite to previous Sammy's Android releases, where a single fix was solving all the issues related to customizations of both kernel and recovery!).
We also have to be aware that the issues may not be a result of flashing different kernel at all, but a result of the changes themselves, ie. disabled knox, disabled encryption of i-dont-really-know-what, etc, etc.
And the most important thing! Since I have heard of AllShareCast/Screen Mirroring for the first time (it probably appeared for the first time in S3/Note2/Note10.1), it always required resetting the flash counter - which could be viewed in download mode and which is NOT the same as Knox flag - to ZERO and that requirement AFAIR remained totally independent from the requirement of having stock boot/kernel (or lib patch). Have you checked the counter state? Did you reset it to zero again using Chainfire's Triangle Away after flashing non-stock kernel (which, obviously, TRIPPED the counter)? Can you check if it is working? Note that at least on my P905, Triangle Away still works flawlessly and resets the counter without any problems and even without a need of reboot!
Please check above info and try if the issue is fixed after running Triangle Away. I am leaving for a short business trip soon, so I'll perform my own tests with AllShare cast until next of the week, however, neither today nor tomorrow...
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
cavkic said:
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
Click to expand...
Click to collapse
Argh possibly too many dots in filename... will correct it tomorrow.
cavkic said:
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
Click to expand...
Click to collapse
same here...
Hi,
I have a problem with screen mirroring.
Installed the patch and mirroring connects to the dongle, but the TV screen turns just black.
The dongle works perfect with HTC One M8, it must be a softwareproblem?
Thanks for help!!!
Will this work on the P905V (Verizon Variant)? I need to downgrade the permissions in my Security in order to use Towelroot, because they're set to Medium and I believe that prevents Towelroot to work properly. Most of the other Note 12.2 variants have been rooted....except the Verizon version.
Can anyone give me some advice please. When I enter the command in terminal emulator I get an error saying "Unable to open chown. No such file or directory". Am I missing something obvious lol.
Will this work on p907a AT&T version of note pro 12.2?
Sent from my SAMSUNG-SM-P907A using XDA Premium 4 mobile app
cnote74 said:
Will this work on p907a AT&T version of note pro 12.2?
Sent from my SAMSUNG-SM-P907A using XDA Premium 4 mobile app
Click to expand...
Click to collapse
On the topic name it says [P905 LTE ONLY], and your device is some different..
tdetroit said:
Will this work on the P905V (Verizon Variant)? I need to downgrade the permissions in my Security in order to use Towelroot, because they're set to Medium and I believe that prevents Towelroot to work properly. Most of the other Note 12.2 variants have been rooted....except the Verizon version.
Click to expand...
Click to collapse
I would like this answered as well. I also have the "v" variant. Maybe saying LTE includes many? See my link I attached, found while investigating this specific question.
http://www.usatoday.com/story/tech/2013/07/07/sprint-att-verizon-phones-network-carriers/2486813/
Ever since I rooted my tablet it goes on random reboot kicks. I want to start over. Also TWRP will not stick when I try to flash it.
I have many issues which I'm currently posing in their appropriate forums. It would be nice to wipe to a rooted stock.
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Thanks. The Galaxy is connecting to theTV, but the screen is only turning black - no Display...
Any idea?
Thank you.
esgie said:
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Click to expand...
Click to collapse
esgie said:
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Click to expand...
Click to collapse
I tried both methods and still get no devices found when I turn on screen mirroring.
ColBill said:
I tried both methods and still get no devices found when I turn on screen mirroring.
Click to expand...
Click to collapse
Hm.
This is weird, as the problems with allshare cast + custom kernels is not that "no devices are found" but that devices ARE found without any problem but the connection process fails after a few secs. This solution may help with the issue i described, but it will surely not solve the problem with no peers detected at all.
No peers detected = problems with wifi direct (are you able to send files between wifi direct between devices?)
Can you tell me what is your exact device config? And are you using allsharecast dongle or other third party hardware?
@fokus
Only one: also reset flash counter with Triangle Away and then try again. And make sure you spell the value in the command as "disable" not "disabled" - it's tricky and one can miss it...
Well, there are two additional things to add.
Guys, make sure you have updated Samsung's ScreenMirroring firmware update app to the latest version. And check out the samsung mirroring fix app in google play, which solves some issues for various devices (dunno which ones exactly as i have never been in need of using it).
The fix half worked for me lol. The tablet now connects fine to the Netgear PTV3000 but all I get is black screen. Step in the right direction though as at least it connects now. Just need to get a picture to show lol.
@Cpasjuste,
In the image headers I noticed that the ramdisk and tag addresses have changed.
ramdisk addr: 0x02000000 -> 0x01000000
tags addr: 0x01e00000 -> 0x00000100
Please correct me if I'm wrong...
The bootloader (lk) loads the ramdisk and kernel tags (device tree) at these physical RAM locations.
@ggow
Yes i saw that but it have no effect. I'm focusing on the .dt part because I found a few things :
- The DT images can correctly be extracted with a tool named "mkboot".
- When using the DT image from kk kernel, the bootloader complains about DT not found (fastboot boot boot.img)
- Opened both DT image in hex editor, noticed some differences in the headers. I switched kk DT headers by jb DT headers, the bootloader don't complain
anymore so I guess it can now found it. But the kernel will just hang immediately.
- The DT syntax seems to have changed (arch/arm/boot/dts/thor.dtsi), this may be the problem for our old bootloader ?!
- Now I'd like to use compiled dt from kk kernel, but has you may have noticed the DT compilation fail about "fb_mem" not declared. I think I need to fix this, then maybe use old jb tools ( $KERNEL_OUT/scripts/dtc/dtc -p 2048 -O dtb -o thor-v1.dtb arch/arm/boot/dts/thor-v1.dts) to compile them, unlike kk kernel which now compile them with the kernel.
From what iv read dt, kernels and bootloaders are linked together, so there is also maybe some changes to be done in the dt sources. But this start to be out of my knowledge.
I asked to hashcode for that but I guess he is very busy.
Cpasjuste said:
@ggow
Yes i saw that but it have no effect. I'm focusing on the .dt part because I found a few things :
- The DT images can correctly be extracted with a tool named "mkboot".
- When using the DT image from kk kernel, the bootloader complains about DT not found (fastboot boot boot.img)
- Opened both DT image in hex editor, noticed some differences in the headers. I switched kk DT headers by jb DT headers, the bootloader don't complain
anymore so I guess it can now found it. But the kernel will just hang immediately.
- Now I'd like to use compiled dt from kk kernel, but has you may have noticed the DT compilation fail about "fb_mem" not declared. I think I need to fix this, then maybe use old jb tools ( $KERNEL_OUT/scripts/dtc/dtc -p 2048 -O dtb -o thor-v1.dtb arch/arm/boot/dts/thor-v1.dts) to compile them, unlike kk kernel which now compile them with the kernel.
From what iv read dt and kernels are linked together, so there is also maybe some changes to be done in the dt sources. But this start to be out of my knowledge.
Click to expand...
Click to collapse
I noticed the "fb_mem" not declared error and couldn't find any reference to it anywhere. I switched the dt.img header also and got to the point where the kernel was not dumping out to fastboot any more, but instead bootloops.
I have messaged amazon once again to post the source code for apollo and thor for update .4.1.1 .
Hehe we are at the same point it seems (nowhere)
Today I did spent a lot of time on this. After a lot of dt hacks/test I'm unable to resolve this problem for now. So I had another idea and started to port kexec hardboot for our device. I'm at the point where is successfully load kernel and DT (something is different for our device, the msm_id struct, which I solved) and reboot but will hang or restart just after a few seconds of the reboot. I think I'm almost there but I may have some problem to find correct memory addresses which are not overwritten by the boot loader. Let me know if you want to take a look I'll upload patches. But well even if we succeed we may still encounter the same DT problem.
In the "dt.img" there is 3 dtb files in, which are scanned by the bootloader for the correct hw revision. I did find that our device use the "thor-v2-apq.dts/.dtb" dt file for booting (not the thor-v1 nor v2) which correspond to our hardware revision. This is in correlation to the 4.1 kernel which only compile this dtb.
When loading the 4.1 dt image with kexec I was able to debug and see that while the header of each dtb parts have changed, there's still the correct hw revision included (of course!?). This one is correctly loaded by kexec and so probably by the bootloader (but in the new dt.img we still need to modify the img header for our bootloader to find it). By the way, I wonder how this final dt.img is built !?
I just don't know yet what is the thor.dtsi file in the 4.1 kernel, the one missing the fb_mem def. This is not included in the dt.img so should it be modified to match our old thor-v2-apq.dts instead the new one ?
By the way manual compilation (and decompilation!) does work with the dtc utility (apt-get install device-tree-compiler).
Yes, upload the the patches for kexec. Definitely interested in taking a look. I have configured a kernel last night with kexec config enabled (great minds think alike)
This DT problem is troubling me. Perhaps not everything is included in this kernel for Apollo or Thor to boot.
I received a reply from amazon, they said they will post the missing source for the last 3 updates very soon (no idea of time frame).
Sent from my Full Android on C6603 using Tapatalk
I don't think the sources are the problem as we have it on stock 4.1 boot.img. I'll upload the patches tomorrow with a little briefing.
@ggow : 4.1.1 kernel booted (not from sources. As you noted this sources may be incomplete).
I'll post the kernel this night, with a clean 4.1.1 system if i have the time.
Cpasjuste said:
@ggow : 4.1.1 kernel booted (not from sources. As you noted this sources may be incomplete).
I'll post the kernel this night, with a clean 4.1.1 system if i have the time.
Click to expand...
Click to collapse
Good News, well done
ggow said:
Good News, well done
Click to expand...
Click to collapse
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img
Cpasjuste said:
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img
Click to expand...
Click to collapse
Good work looking forward to testing it out.
Sent from my Optimus G using XDA Free mobile app
cdub50 said:
Good work looking forward to testing it out.
Sent from my Optimus G using XDA Free mobile app
Click to expand...
Click to collapse
This is a wip for you. You need to wait for a root exploit on 4.1.1 for using it !
Cpasjuste said:
This is a wip for you. You need to wait for a root exploit on 4.1.1 for using it !
Click to expand...
Click to collapse
Ah gotcha. Hopefully that will be sooner than later.
Sent from my Optimus G using XDA Free mobile app
Cpasjuste said:
Finally, sorry for the delay So here is the modded 4.1.1 boot image. In short : binary extract correct dts from 4.1.1 stock dt image and happend it to 4.1.1 stock zImage.
Didn't had the time to finish my gapps rom based on 4.1.1 but should not be too long
http://android.mydedibox.fr/hdx/boot-4.1.1.img
Click to expand...
Click to collapse
Thanks for that
Which number dts is the correct one (there are 3). I need to do the same for Apollo...
ggow said:
Thanks for that
Which number dts is the correct one (there are 3). I need to do the same for Apollo...
Click to expand...
Click to collapse
From what i remember this is the third (which is thor-v2-apq.dtb)
Well, cm is still a ***** to get ported :/, tree days on it without success.
Else the new odex framework is not deodexable by baksmali. If you ever have a solution let me know (You may not need that but I'm in a dead end).
So @ggow, did you made some progress on resurecting your device ?
In the meantime i did get msm aosp up and running ! (but no wifi, qcmediaplayer not found for no apparernt reason which prevent some audio to work, slow ui transitions and probably more stuff to fix).
Cpasjuste said:
So @ggow, did you made some progress on resurecting your device ?
In the meantime i did get msm aosp up and running ! (but no wifi, qcmediaplayer not found for no apparernt reason which prevent some audio to work, slow ui transitions and probably more stuff to fix).
Click to expand...
Click to collapse
So far no...
What I think could have happenned is the synaptic dsx firmware and configuration has been updated or corrupted by the new kernel.
I am in the process trying to figure out exactly what I need to do to fix it. I have found a utility which can be used to force an update to an older version of synaptic firmware.
I might have to write a utility to extract the firmware and configuration area from a working device.
Will let you know what I find.
Sent from my Kindle Fire HDX 7 using Tapatalk
ggow said:
So far no...
What I think could have happenned is the synaptic dsx firmware and configuration has been updated or corrupted by the new kernel.
I am in the process trying to figure out exactly what I need to do to fix it. I have found a utility which can be used to force an update to an older version of synaptic firmware.
I might have to write a utility to extract the firmware and configuration area from a working device.
Will let you know what I find.
Sent from my Kindle Fire HDX 7 using Tapatalk
Click to expand...
Click to collapse
Yep i was just going to talk you about this. I'm trying to fix wifi on the aosp build and discovered this lines in dmesg :
<6>[ 6.404807] synaptics_dsx_i2c 2-0020: fwu_start_reflash: Requesting firmware image Synaptics.3.B.thor.img
<6>[ 6.414184] synaptics_dsx_i2c 2-0020: Firwmare size 45056, config size 512
<6>[ 6.421216] synaptics_dsx_i2c 2-0020: Device firmware id 1509905.
<6>[ 6.427045] synaptics_dsx_i2c 2-0020: Device config ID 0x13, 0x07, 0x00, 0x02
<6>[ 6.434233] synaptics_dsx_i2c 2-0020: .img config ID 0x13, 0x07, 0x00, 0x02
<6>[ 6.441127] synaptics_dsx_i2c 2-0020: Nothing needs to be updated
<6>[ 6.447230] synaptics_dsx_i2c 2-0020: fwu_start_reflash: No need to do reflash.
Click to expand...
Click to collapse
Thank you for your work! I hope your problem will spill over into different firmware for our device. With the support of LTE I hope.
Note: This thread is here mostly for historical purposes. While Xposed is supported in various forms [EdXposed and LSPosed], developent on the Xposed primary app has completed. Xposed framework compatible modules are still in active development and supported by their respective developers.
Click to expand...
Click to collapse
This is the announcement thread for Xposed for Lollipop, Marshmallow, Nougat and Oreo. I'll post all relevant news here, so subscribe to it if you'd like to stay informed.
You can find a list with Q&A about Lollipop support on the XDA Portal. Please read it, you will find many answers there. Also see this article with much background information on new stuff for Nougat.
Please install it only if you're willing to take the risk of boot loops. Just because it's working fine and stable for me doesn't mean it will work for everyone the same way.
Downloads:
XposedInstaller_*.apk from this thread: Must be installed to manage installed modules, the framework won't work without it.
xposed*.zip from https://dl-xda.xposed.info/framework/: Must be flashed with a custom recovery (e.g. TWRP) to install the framework.
SDK21 is Android 5.0 (Lollipop), SDK22 is Android 5.1 (also Lollipop) and SDK23 is Android 6.0 (Marshmallow).
For Nougat, SDK24 is Android 7.0 and SDK25 is Android 7.1.
For Oreo, SDK26 is Android 8.0 and SDK27 is Android 8.1.
I only support the latest Xposed version per Android release!
xposed-uninstaller*.zip from https://dl-xda.xposed.info/framework/: Can be flashed with a custom recovery (e.g. TWRP) to uninstall the framework.
The small .asc files are GPG signatures of the .zip files. You can verify them against this key (fingerprint: 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333). That's actually the master key, the files are signed with subkey 852109AA.
Known issues:
- Before Nougat: Bootloops on Samsung stock ROMs. That's due to Samsung's changes to ART. There are unofficial builds that work around this by deodexing and adjusting the ROM.
- Sony seems to have shipped some ROMs with corrupted services.odex (the embedded .dex is invalid). Those ROMs will bootloop with a "Fatal signal 6" or "No pending exception expected: java.lang.ArrayIndexOutOfBoundsException" error, which I unfortunately cannot fix (see https://github.com/rovo89/Xposed/issues/64)
- Dell ships (at least) their Venue 8 7840 with a non-standard version of ART that is somewhere between 5.1 and 6.0 which obviously isn't supported by Xposed (see https://github.com/rovo89/Xposed/issues/77)
For discussions, please use the discussion threads (Lollipop / Marshmallow / Nougat / Oreo) or another matching one in this subforum.
As you have probably noticed, more than 2,000 posts have been made in the original thread about Xposed on Lollipop. I'm really overhelmed by all your feedback! Also many thanks to those people who have donated already, it's great to see how much Xposed means to you.
Although so much discussion and helping each other is great, it's hard for anyone (including me) to follow. Hence, I have decided to create this thread were only I (and possibly the XDA moderators) will give some updates. This will make it easier for me to inform you about the current status, bugs I know about and so on. Feel free to subscribe to it or simply check from time to time. I'm not sure yet about the best way for me to get a consolidated overview of existing issues that have been confirmed by several people and ideally already have a sufficient information (like logcats, clear description of the error, ...) attached, but I hope we can work something out.
Current status (Feb 19):
The most important issue seems to be the incompatibility with Samsung stock ROMs, especially because it's leading to boot loops. I have been working hard on fixing this in the days since the release, however it's not just a single spot that needs fixing. Thanks to GermainZ for testing and providing good log files! So far, I have detected the following issues:
- Enhanced .oat file format: Samsung has added a "TypeLookupTable", probably for performance reasons. The table itself will be ignored by Xposed, but it also means that the file format is slightly different. I have finally understood what they have done and added some logic to skip the referenes to this table.
- Different size of the String class: They have added a clear() method, which is unusual as strings are usually immutable. As this class is one of few that have special support in native code, I had to add one entry to the virtual table of the class.
- Additional fields in DexCache class: Offsets to some fields are different due to this and need to be handled in native code (as this another central class with native parts directly implemented in ART).
- Verifier rejects ViewDebug class: Doesn't seem to be overly critical to me, yet to be tested whether it's working fine with original libraries.
- Implementation missing for some native methods: Some methods in the reflection classes have been implemented in native code instead of Java. This means I will have to implement them as well.
The changes done by Samsung are bigger than I expected, especially given that ART is very complex and mostly undocumented. Anyway, I still think that once these issues have been overcome, it's better to replace the libaries than trying to manipulate data structures and behavior from "outside" (app_process). Think about it: If they have done such big changes, it's very likely that offsets in these data structures are different from AOSP and would need special handling as well.
It would of course be helpful to have an uninstaller ZIP in case you run into a bootloop. I didn't have time for that yet, but maybe someone can build an initial version that basically reverses the steps of the installer ZIP. For the ART libraries, that should be rather easy. You might want to stay away from moving app_process32 back in case you have SuperSU installed. It will need a special procedure to ensure you don't break either part or even your ROM.
There are other issues for sure, for example it seems that some methods cannot be hooked. That's something that needs more investigation, but I would like to fix the more critical issue like the ones for Samsung first.
That said, I won't be able to work on Xposed for the next days, definitely not before Monday. Keep in mind that this isn't my fulltime job and that an alpha phase might take some time. It would be illusionary to assume that we reach a stable state after a few days, with all the changes that have been done.
I have just uploaded alpha2. It fixes several issues:
java.io.IOException: Invalid argument while reading /data/data/de.robv.android.xposed.installer/conf/modules.list (sometimes it worked fine after a soft reboot), see https://github.com/rovo89/Xposed/issues/25
ClassNotFoundException for system services (e.g. ActivityManagerService) shown in the log, see https://github.com/rovo89/XposedBridge/commit/6b49688c929a7768f3113b4c65b429c7a7032afa
Resources-related incompatiblity on newer CM12-based ROMs
Hooks for very simple methods not working, see https://github.com/rovo89/android_art/issues/4
app_process version not displayed in XposedInstaller
When you flash the new files, the next boot might take a bit longer, as it effectively clears the Dalvik cache (which is necessary because of a change in the ART compiler).
Note that this version is still not compatible with Samsung ROMs (custom ROMs might work if they're not based on stock ROMs). Don't install it, otherwise you'll get into a bootloop and need to restore your backup!
I have already done a lot of investigations and adjustments, as also mentioned in the previous post. However, there are still differences that need to be addressed and it will take more time to resolve them. I can't give any ETA on that.
Ok, quick status update.
Sure, I have heard that Android 5.1 is out. However, it currently makes more sense for me to stablize Xposed for Android 5.0, as I have two productive devices plus the Genymotion emulator running on it. Hopefully, it can then be ported to Android 5.1, but that's hard to tell without having had a look at it.
It's generally hard to estimate any timelines for Xposed-related stuff, for mainly two reasons:
a) Working on Xposed is mainly analysis of AOSP code, traces, closed-source files, followed by some development and testing (often trial and error). I never now which other obstacles are still undiscovered, so the effort is unclear beforehand.
b) Even if I know the effort (= net time), I can't say when I will have the time to actually work on it. For example, this week I probably won't spend a single hour on development. Sorry, but I'm not going to sacrifice my private life for Xposed and I can't spend several hours per evening for this project (anymore).
One of the next steps will be the creation of some scripts that help me to compile and package Xposed. Apart from simplification for me, I hope that this might help other experienced developers to try and contribute themselves (e.g by analysing the issues they noticed themselves).
So much for now, keep enjoying the stuff that is already working and please refrain from asking me when Xposed for 5.1 will be stable... I simply don't know that myself.
rovo89 said:
One of the next steps will be the creation of some scripts that help me to compile and package Xposed. Apart from simplification for me, I hope that this might help other experienced developers to try and contribute themselves (e.g by analysing the issues they noticed themselves).
Click to expand...
Click to collapse
It took longer than expected, but I also think it's better than what I had planned originally:
https://github.com/rovo89/XposedTools
I hope this makes it easier for others to compile the native parts of Xposed and the modified ART runtime themselves and get involved, just like @romracer did. It also makes it easier for me to build and package the Xposed framework, as it was quite a hassle to make sure that all files are compiled correctly, pushed to my PC etc.
I have just uploaded a new flashable ZIP for Xposed 3.0 alpha3 (xposed-sdk21-arm-20150426.zip).
You only need to flash the ZIP again, the Xposed Installer app remains the same (and therefore still shows version alpha2). If XposedBridge.jar has version 64 after a reboot, the new version is active.
Changes:
- Fixed issues with replacing drawables
- Fixed NoSuchMethodError in handleInitPackageResources
- Possibly fixed some errors on ROMs that start in permissive SELinux mode and switch to enforcing mode later
As the question probably comes up:
- No, this version doesn't support Android 5.1 yet.
- No, this ZIP doesn't support arm64/x86 processors yet.
I will eventually support them as well, but as there are unofficial versions for these, I try to work on a few known issues for Android 5.0 before (when I find time for it).
Regarding Samsung ROMs: No progress. No ETA. No promise that it will be supported, although I don't exclude it either. It's simply unclear what further differences between their and AOSP's ART variant come up.
alpha4 (20150430) is now available. It fixes bootloops and crashes on some ROMs, especially on Sony devices. In the logs, there used to be "Too many open files" errors.
References for this bug:
https://github.com/rovo89/Xposed/issues/31
http://forum.xda-developers.com/crossdevice-dev/sony/workaround-bootloops-xposed-lollipop-t3089203
http://forum.xda-developers.com/z3/general/xposed-bootloops-lollipop-t3085627
I have just upload files for a big update. It includes many general improvements/changes and some smaller fixes.
One of the changes is that I decided to avoid confusion about all the different (yet similar) version numbers for installer, framework zip, app_process and XposedBridge by reducing it to two version numbers:
The framework (i.e. all the files in the flashable) zip is versioned with integers (65 for this release). This is at the same time the Xposed API version. Unofficial builds should use suffixes to label their releases.
The Xposed Installer app will continue to use the well-known, human-readable version numbers, e.g. 3.0 alpha3 for this release.
The next bigger change is the installation script in the flashable ZIP. I use a modified fork of BusyBox now to keep the scripts clean and work with a well-known environment. This should make it pretty reliable, even in case some weird recoveries forget to include the "unzip" command. Those who are interested in the technical details should check out the GitHub project.
While I was working at it, I finally built flashable uninstallation ZIPs as well. They revert all actions done by the installation script, provided you didn't delete the backups (<filename.orig>). These ZIPs are only tested with Android 5.0.
The other changes are:
- Installer: Display the installed framework version in green, instead of a static hint about flashing the framework via recovery.
- Fix for incomplete logs on some devices, see https://github.com/rovo89/Xposed/issues/34
- Fix for updated modules crashing until the next reboot, see https://github.com/rovo89/Xposed/issues/22
- Ignore unknown parameters to avoid bootloops on some devices, see https://github.com/rovo89/android_art/issues/7
- Some other internal improvements
- Some cherry-picked ART commits from AOSP
- Devs: Allow hooking native methods, see https://github.com/rovo89/Xposed/issues/28
- Devs: Several debugger fixes, see https://github.com/rovo89/android_art/issues/1
I'm also uploading builds for arm64 and x86 devices. I have tested them on my Nexus 9 and on the Genymotion emulator and didn't notice any issues. The unofficial builds don't seem to be modified from my source code either and I didn't get pull requests on GitHub for these platforms, so I assume that they work fine.
By the way, in case you're a dev (or just interested) and want to try out your modules on Genymotion, you can use this collection of scripts to faciliate the Xposed framework installation on Genymotion. Just follow the instructions, then you can simply drop the x86 framework installation ZIP on the emulator window to install the framework. Don't forget to reboot afterwards.
So much for now. Be assured that official Android 5.1 support will come sooner or later, but the changes above required quite some debugging, development and strategic thinking. It's nice to see that some unofficial ports fill the gap for those who don't want to wait.
About M: The AOSP tag for the preview seems to be just a placeholder, just like it was for the L preview. I haven't tried, but I doubt that compiling ART from this tag will fit to the M preview image. Hence, I won't be investing any of the time (that I don't have anyway) to try and get Xposed running on the preview image.
Those who had issues with installer version 3.0 alpha3 displaying the framework as not installed, please try 3.0 alpha4. ProGuard optimized a bit too much in one very specific case... unfortunately, this never appeared during development, just in the release build.
If modules aren't loaded after a reboot because modules.list wasn't found, try to disable/enable any module. This will write the file again.
One addition to the changes in framework v65: The ZIP files are now signed. This wasn't possible before integrating the custom BusyBox version as some recoveries failed to unzip the signed ZIP.
I have just uploaded ZIPs for Xposed framework version 66 and also replaced the uninstaller ZIPs. There are no changes in the framework itself, so if you installed version 65 successfully, there's no need to update. If you got messages containing "Invalid argument" or "Wrong SDK version: 19, expected 21" while flashing the ZIP files, this should fix them. Thanks to @romracer for the fix!
EDIT: Had to reupload. If you downloaded the ZIPs within the first 15 minutes after this post was published, please download them again.
New files for framework version 67 are now available. They fix an issue with recoveries that have SELinux disabled (even though they might claim that "Full SELinux support is present" in the log, like TWRP does). This seems to have happened mainly on LG devices and caused boot loops, but could affect others as well. Details about the fix are in this commit: https://github.com/rovo89/XposedTools/commit/c55ac907e16947d66012950d119d8db1aea69124
The uninstaller has also been updated, although it's unlikely that it would have caused real issues.
framework version 68 fixes two reported crashes:
"Fatal signal 11" reported for dex2oat or "Compiler driver" in the Xposed log. I have seen a few posts about such issues, but the one I tested the fix with was about Quickoffice. If you notice further issues like this, please report them on GitHub with the full logcat (as only that contains the command line that crashes).
"com.android.phone has stopped" on LG G3. Don't confuse this with support for encrypted apps (LGWeather, LGCover), this can't be fixed unless someone comes up with a decrypter, ideally one that can be executed on the device.
rovo89 said:
Don't confuse this with support for encrypted apps (LGWeather, LGCover), this can't be fixed unless someone comes up with a decrypter, ideally one that can be executed on the device.
Click to expand...
Click to collapse
I had another look at their encryption, or rather the library they use for it. Fortunately, all the decryption logic is in that library (liblgalmond.so), not in ART itself. So I did a lot of digging into their libraries and finally figured out how to call the relevant functions to detect and decrypt their encrypted apps on the fly. That's the requirement to recompile and run these apps.
So here it is, framework version 69 with support for LG's encrypted apps (LGCover, LGWeather, maybe more). Please make sure to clean your Dalvik cache after flashing the ZIP if you have an LG device and had issues with these apps.
It turned out that some LG devices (at least G2 mini and G Pad 8.3) are using encrypted precompiled (odex) apps. These need to be handled differently than apps which contain just the encrypted dex file. With framework version 70, Xposed supports both encrypted dex and odex files. Again, clearing the Dalvik cache might be necessary. If you don't have an LG device or don't get FCs, you can skip this update.
In framework version 71, I have fixed a boot loop on various devices/ROMs related to the "SettingsProvider". If you were getting boot loops with earlier versions, you might want to give this a try.
Apart from that, it should now work properly with Sygic (after reinstalling the app or wiping the Dalvik cache). Note that some modules might not work properly with this app, as they "hack" Android's resource processing (e.g. for images/texts) on a low level. As this conflicts with Xposed (which does a similar thing), I had to disable parts of the API for this app.
I finally created an official version for Android 5.1 (aka SDK22). You can download it as v72 from the first post.
This version is not directly based on @romracer's port, however there aren't many differences. He had merged AOSP 5.1 into the Xposed codebase, I did it the other way around and used this opportunity to reorder and combine the commits. So it's a little bit cleaned up now, which will hopefully make it easier to port these changes to future Android versions. I have also cherry-picked two of his changes that weren't in the offical version yet: A fix for a special case in resource handling on 64-bit and compression of the backup Xposed creates during its installation. Many thanks to @romracer for providing the unofficial version - this gave me the chance to fix and improve many things (which were in turn merged by him and others).
That said, there are also a few new changes:
- In error messages, the Android version is now display as well, e.g. "Wrong Android version: 5.1 / SDK22 ... This file is for: 5.0 / SDK21"
- The files for Android 5.1 can now handle gzip-compressed odex files (*.odex.gz). Those files only exist on certain ROMs (e.g. CM) that merged a few commits proposed by Intel. These commits weren't accepted into AOSP because the way they're handling the compressed files has some flaws. With Xposed installed, these files will be unpacked on-the-fly and recompiled.
The gzip support might also be interesting for ROMs where the /system partition is almost full. It should be possible to gzip some of the .odex files before installing Xposed in order to free up some space. This should work on any odexed 5.1 ROM, even if the Intel commits aren't included. However, this would be very experimental. Volunteers are welcome, but don't forget to create a backup.
Finally, I have updated the uninstaller zips. They include a timestamp now, as new installer zips might require new uninstaller versions. You should always be able to uninstall older versions with the latest uninstaller though. v72 requires at least the uninstaller from today (20150831).
With framework version 73, a bug on 64-bit ROMs is fixed which prevented modules from reading their preferences. I believe that the root cause is a bug in AOSP, but whatever - it should be fixed now. Thanks to @romracer and @cryptyk for the fix.
I have additionally merged a few changes from CyanogenMod. Most of them control when the Dalvik cache is cleared automatically after a bootloop (new feature in 5.1 AOSP, now improved) and one is supposed to increase the compile performance on some ROMs. Don't expect too much though.
In framework version 74, I have fixed some more incompatibilities which could lead to bootloops or crashes. I assume that most of these crash logs contained the string "Incompatible set properties", which is actually a consequence of previous method verification errors. It's hard to say which ROMs and devices were affected - but flashing the new version shouldn't hurt even if everything looks fine with older versions. If you do notice any issues and are sure that it's not caused by yourself, you have higher chances of getting them fixed if you open a detailed GitHub issue (usually I will need at least a full logcat).
I won't be able to work on Xposed for the next 2-3 weeks - no time for development, support or questions at all. If the rumors I have read are right, I should be ready just in time to start porting Xposed to M.
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
This is an update to the Ubuntu Touch build that I shared a while back.which was based on halium 7. Now we are moving to halium 9. Even with quite a few unsolved issues ,these builds are marginal improvement over the previous ones.
This port had been no means easy, in reality, the initial builds was even more buggy compared to previous gen ,but most of them were much easier to fix, as I got lots of help from the porting community.I was able to get it to a booting state in about 3 months time as compared to more than a year with halium 7 , to be fair the delay was also due to the fact that I was not exactly an android developer or a developer for that matter, and had to read a lot at first .
anyways I share it here as I have reached a point where further bug fixing is beyond my capability . or in other words, Googling error codes and testing all possible methods /solutions don't seem to yield any meaningful full result, I do really wish someone better than me would look into it and make it even better ;- )
In the meantime let me add more Verbose ;-P
What is ubuntu touch
ubuntu touch is different from other oses as it is fork of Linux as compared to all our favorite mobile oses being forks of android. in other words, it is a fully functional Linux os optimized to run on arm64 device in a touch environment.The original idea was conceived by canonical and later they stoped their work and open-sourced the project and transferred the assets to the ubports community, the community is actively improving it, and trying to bring it to feature parity with Android .
whats working on this port
calls,data ,wifi
sound, vibration
auto rotation
auto, manual brightness
Offline charging
GPS
and other misc things
whats partially working
camera (preview and take video works clicking picture not working)
fingerprint (fingerprint wakes the device but cant enroll fingerprints)
Bluetooth (everything works except file transfer)
what does not work
adb,mtp
one of the feature improvements amongst other things is the support for waydroid
Waydroid
waydroid is a containerised approach to get an android environment running in a Linux system with the added advantage of full hardware access.so we can android apps and games natively. more details can be found here. to install way droid open terminal and paste the following
sudo -s
mount -o rw,remount / && apt update && apt install waydroid && waydroid init
It also need a fix as waydroid is intended for treble devices which can be found in this post. Thank you @erfanoabdi for enabling support for non treble devices.
Installation
- flash the halium-boot and the following zip file
- clean flash recommended
- reboot after the initial setup is done
Halium-boot .img
ubuntu_touch_installer_Kenzo_halium9_v7.zip
Please Donate
Every rupee ,euro ,doller counts. It would feel wounderful to be gifted something no matter how small.
If you like to do more, please consider buying me a coffee or may be even another Kenzo.
if you are in India please use this upi id -- > [email protected]
else do pm me.
default user password is " a "
For the History book
ubuntu_touch_installer_Kenzo_halium9_v6.zip
ubuntu_touch_installer_Kenzo_halium9_v5.zip
ubuntu_touch_installer_Kenzo_halium9_v4.zip
ubuntu_touch_installer_Kenzo_halium9_v2.zip
The sources
[https://github.com/mathew-dennis
[https://github.com/LineageOS
[https://github.com/Halium
[https://github.com/ubports
Thankyou
ubports community --> TheKit ,FlowHack, kn8rider divin, ari and everyone else
Redmi note 3 community --> thanks to all Dev's for keeping the device alive for the community .
This port would have never reached anywhere without their efforts..
And the truth is my efforts are very little as compared theirs...thank you ...
changelog
"Why not make something new from old code!" (Also because my pc can't handle A10+ builds)
v7
- updated to latest rootfs (ota-24)
V6
- updated to latest rootfs (ota-22)
- rebuild android image
- auto-brightness
V5. 1 (this is a patch for v5)
- bluetooth (everything else except file transfer )
- offline charging
- gps ( for real this time ) ( as ut dont have A-GPS support 1st fix might take 5+ min ,then it should work as normal)
v5
- gps is working now ( it's broken again)
-changed audio hal to a late start service
-enabled wireless display option (should work on miracast devices ) (not tested )
-fixes from ubports --> magnetometer and notification led is working and other fixes from ota 18 to ota 20
v4
- fixed issue with initial setup --thankyou Kn8Ryder
-audio should come up more often during boot than before
Telegram
If you are interested in bug fixing and contributing to this project , report a bug , click here to reach Telegram group
#Screenshots
what is default user password...
KrutosVIP said:
what is default user password...
Click to expand...
Click to collapse
"123" if u flashed old rom first, else "a"
mathew..denniss said:
"123" if u flashed old rom first, else "a"
Click to expand...
Click to collapse
ok, will try
Touch not working! after initial setup
mathew..denniss said:
"123" if u flashed old rom first, else "a"
Click to expand...
Click to collapse
Working for me, thanks for porting this amazing system.
BraveAmbush said:
Touch not working! after initial setup
Click to expand...
Click to collapse
For me the fix was to firstly install old ubuntu touch, load it and configure. After that,flash bootimage of new Ubuntu Touch with Halium9, then flash .zip with new Ubuntu Touch. It will give error, it is normal - go to /data/ and delete dir "ubports", then try again.
After that - just reboot, system will start with configured profile "Ubuntu"
The password is just "a"
Also, for me sound not working.
KrutosVIP said:
For me the fix was to firstly install old ubuntu touch, load it and configure. After that,flash bootimage of new Ubuntu Touch with Halium9, then flash .zip with new Ubuntu Touch. It will give error, it is normal - go to /data/ and delete dir "ubports", then try again.
After that - just reboot, system will start with configured profile "Ubuntu"
The password is just "a"
Click to expand...
Click to collapse
both flash may end with flash error that not a problem its a busybox compatibility thing.(not relevant )
KrutosVIP said:
Also, for me sound not working.
Click to expand...
Click to collapse
try a hard reboot(long press power button) .it should work afterwards
BraveAmbush said:
Touch not working! after initial setup
Click to expand...
Click to collapse
mathew..denniss said:
both flash may end with flash error that not a problem its a busybox compatibility thing.(not relevant )
Click to expand...
Click to collapse
For me deleting ubports helps to end without error-
When i don`t delete and get error, the system just don`t want to boot.
No animation, just black screen and when reboot
um that for me sound dont work too..
if not delete ubports in recovery and install, it 'll show a short black screen with a small mouse and reboot.
Also there are strange permission issues in the system dirty flashed from halium 7
Can I ask for some clarification? I managed to install the alpha version from your previous post, but how do you flash these update zips? I tried flashing them via TWRP on the device but I keep getting "recovery busybox setup failed" error.
jeangjenq said:
Can I ask for some clarification? I managed to install the alpha version from your previous post, but how do you flash these update zips? I tried flashing them via TWRP on the device but I keep getting "recovery busybox setup failed" error.
Click to expand...
Click to collapse
An update on this, after two more tries of reinstalling old ubuntu touch > flashing halium-boot through fastboot > Flashing zip through TWRP. It flash without issue and booted. Initially the sound isn't working, but after several weird restarts (select poweroff but it restarted, select poweroff but it froze on boot logo, etc etc), sound is working. This is a fun project
updated the flashable zip .. thankyou for the fix @Kn8Ryder
t
jeangjenq said:
Can I ask for some clarification? I managed to install the alpha version from your previous post, but how do you flash these update zips? I tried flashing them via TWRP on the device but I keep getting "recovery busybox setup failed" errotry v4
Click to expand...
Click to collapse
jeangjenq said:
Can I ask for some clarification? I managed to install the alpha version from your previous post, but how do you flash these update zips? I tried flashing them via TWRP on the device but I keep getting "recovery busybox setup failed" error.
Click to expand...
Click to collapse
try v4 ,it has some more fixess.busybox things are gone now
how many minutes does waydroid open to you ?
I did clean install
boot halium + v4 update
then install waydroid thru terminal
loading screen boot logo waydroid? is this alright?
im waiting to it