As the title suggests, I'm looking for information on what is necessary to root Alien Dalvik (4.4) on the Jolla C (hwadaption is based on 5.1 API lvl 22 but Alien Dalvik is not, it's based on 4.4 apparently)
On Jolla Phone, we had one superuser binary that we linked to in the directories opt/alien/system/bin and xbin and in /system/bin and xbin named su
The same procedure seemingly does not work. I've tried putting one of the many available su binaries in the respective places without success.
Sadly I have no clue where to look next. Does Android 4.4 need more than just the su binary for root access? On Jolla Phone Android 4.1.2 it was enough.
Thanks for any help in advance!
It is rooted.
Norpan70 said:
It is rooted.
Click to expand...
Click to collapse
Can you post a link to the process involved? I'm not talking about the SailfishOS side of the OS, I'm talking about the Alien Dalvik runtime... I have yet to find a way that works.
Thanks
MoritzJT said:
Can you post a link to the process involved? I'm not talking about the SailfishOS side of the OS, I'm talking about the Alien Dalvik runtime... I have yet to find a way that works.
Thanks
Click to expand...
Click to collapse
Actually, it seems semi rooted, I thought it was due to the fact that I earlier renamed the su files to be able to play pokemon on my phone. Now that I checked with root check it said that its not rooted, SuperSu seems to start tho, which it doesn't if it's not. So not properly rooted. My bad!
MoritzJT said:
As the title suggests, I'm looking for information on what is necessary to root Alien Dalvik (4.4) on the Jolla C (hwadaption is based on 5.1 API lvl 22 but Alien Dalvik is not, it's based on 4.4 apparently)
On Jolla Phone, we had one superuser binary that we linked to in the directories opt/alien/system/bin and xbin and in /system/bin and xbin named su
The same procedure seemingly does not work. I've tried putting one of the many available su binaries in the respective places without success.
Sadly I have no clue where to look next. Does Android 4.4 need more than just the su binary for root access? On Jolla Phone Android 4.1.2 it was enough.
Thanks for any help in advance!
Click to expand...
Click to collapse
NECRO REPLY INBOUND!!!
why do/did you need this? Usually people need root to interact and modify critical (or not so critical) components of android, and last I checked, Sailfish only uses the android base for Hardware support, nothing else, and I don't think SetCPU or similar will have much effect because if I remember correctly, SFOS uses it's own kernel.
Galaxyninja66 said:
NECRO REPLY INBOUND!!!
why do/did you need this? Usually people need root to interact and modify critical (or not so critical) components of android, and last I checked, Sailfish only uses the android base for Hardware support, nothing else, and I don't think SetCPU or similar will have much effect because if I remember correctly, SFOS uses it's own kernel.
Click to expand...
Click to collapse
Modifying critical files of the Alien Dalvik runtime such as e.g. build.prop etc. is possible through SailfishOS side with root rights.
However some apps that manage system notifications on the android runtime require root permissions to modify what is shown and what is not. That's just one example of many. Another would be backup solutions that want to write apps data aside from only installing the APKs
I find it ridiculous that Jolla didn't order a rootet or rootable Alien Dalvik from Myriad. I'm basically god on the SFOS side but the damn sandboxed Alien Dalvik is a world on its own? Nope that's not acceptable.
I hope you see where I'm going with this. By the way I have given up on figuring out a way since this time with Android 4.4 as Alien Dalvik base there seems to be another system security in place that requires to modify more than just one file. I'm clueless
Cheers
MoritzJT said:
Modifying critical files of the Alien Dalvik runtime such as e.g. build.prop etc. is possible through SailfishOS side with root rights.
However some apps that manage system notifications on the android runtime require root permissions to modify what is shown and what is not. That's just one example of many. Another would be backup solutions that want to write apps data aside from only installing the APKs
I find it ridiculous that Jolla didn't order a rootet or rootable Alien Dalvik from Myriad. I'm basically god on the SFOS side but the damn sandboxed Alien Dalvik is a world on its own? Nope that's not acceptable.
I hope you see where I'm going with this. By the way I have given up on figuring out a way since this time with Android 4.4 as Alien Dalvik base there seems to be another system security in place that requires to modify more than just one file. I'm clueless
Cheers
Click to expand...
Click to collapse
Ah, I see. I was wondering, then again I have never gotten alien dalvik set up on either of my sailfish devices (Nexus 7 2013 flo, and Droid RAZR M xt907), so I wouldn't know. Also where can I buy an Jolla Tablet and Jolla C? I Would sell all my devices in a a heartbeat and just use Jolla devices if I could find them. I live in Australia if that matters.
Related
I don't know how I missed this!
Android Rootkit is just a phone call away
Now, hopefully after Defcon, the details will go public, and since the Rogers Dream won't be patched (that's what you get for never giving us OTA updates), I'm sure it'll be adapted into a local exploit as well.
"This could be done by building the rootkit into a rogue application sold via the Android Market, or by exploiting a new, unpatched bug in Android's Linux kernel that could allow the program to be installed."
** actually, it would require BOTH.
And at this time, there ARE NO known kernel bugs affecting Android's kernel.
The old "1-click-root" app demonstrated this kind of thing, and DID exploit a kernel bug, which HAS SINCE BEEN PATCHED.
This thing can ONLY hurt a ROOTED phone, and even then, the su app will pop up saying "gee, this app wants root, should we let him?"
lbcoder said:
"This could be done by building the rootkit into a rogue application sold via the Android Market, or by exploiting a new, unpatched bug in Android's Linux kernel that could allow the program to be installed."
** actually, it would require BOTH.
And at this time, there ARE NO known kernel bugs affecting Android's kernel.
The old "1-click-root" app demonstrated this kind of thing, and DID exploit a kernel bug, which HAS SINCE BEEN PATCHED.
This thing can ONLY hurt a ROOTED phone, and even then, the su app will pop up saying "gee, this app wants root, should we let him?"
Click to expand...
Click to collapse
I believe flashrec exploited the sock_sendpage() glitch. It may be possible that they have discovered a new exploit similar to the sock_sendpage, and simply haven't made it public. Remember, that one was present since 2001. It can be built into any apk, and instead of giving a shell root access, it can run background processes with a superuser permission.
Just food for thought.
Which will easily be fixed with a wipe and reflash if it -does- happen.
...right?
r3s-rt said:
Which will easily be fixed with a wipe and reflash if it -does- happen.
...right?
Click to expand...
Click to collapse
Yes, as long as the rootkit doesn't block fastboot and ADB
I'm pretty sure it can't stop you from getting to recovery, though? Either way - this would be just more of a pain in the ass for me.
However, some people are genius enough to store crucial information on their phone such as S.S. numbers and credit card numbers, and people are dumb enough to install this and give it su permissions. :/
Bought a new nexus 7 yesterday (after having my old one stolen...) and I decided to root and install AOKP JB MR1 Milestone 1. I'm really impressed with it but I was surprised to find the AOSP browser rather than Chrome and a lack of Performance Control.
I tried to install Chrome as a system app (download from Play, push from /data/app to /system/app and set permissions to rw-r--r--) and rebooted. I was again surprised when I found that "Chrome's installation was incomplete." It worked fine in /data/app but I am now curious as to why it won't work in /system/app. (Sorry if this sounds nooby, I haven't dealt with rooting Nexus devices before, I only rooted my crappy old GT-S5830)
Does anyone have a solution? Missing lib files or something else that I need to transfer over?
And as a sidenote, is Performance Control compatible with the N7 on this build? And does anyone have a working version of it?
why are you trying to force it to be a system app? what benefit do you think its going to give you?
Pirateghost said:
why are you trying to force it to be a system app? what benefit do you think its going to give you?
Click to expand...
Click to collapse
No major benefits, but it does save some space on the data partition (and my system partition is only half full). I'm just curious as to why it won't execute properly when installed and upgraded as a system application. I'm fine with having it in /data/app, I was just curious.
Anyone have an answer?
I found THIS
I have been trying to set ART as my runtime environment.It asks me about the change in the library and reboots my device.But then again while checking in the developers option it shows me dalvik as the runtime environement.What should I do in order to use the delights of ART.My phone is rooted with stock kitkat image.
cnilesh said:
I have been trying to set ART as my runtime environment.It asks me about the change in the library and reboots my device.But then again while checking in the developers option it shows me dalvik as the runtime environement.What should I do in order to use the delights of ART.My phone is rooted with stock kitkat image.
Click to expand...
Click to collapse
Do you use Xposed? I know that only works with Dalvik at the moment and actively resets that setting to Dalvik.
JASN_DE said:
Do you use Xposed? I know that only works with Dalvik at the moment and actively resets that setting to Dalvik.
Click to expand...
Click to collapse
Yeah i use that module just to extent my greenify features.Is there any way to use exposed and make ART work at the same time?
Quote from rovo89: "After installing Xposed, the runtime gets reset from ART to Dalvik. Can you stop it please?
You can be glad that I implemented this, otherwise you would be in a bootloop know. Xposed isn't compatible with ART (yet). It's a completely different architecture with pretty much no documentation. I hope that I can rewrite Xposed for the ART runtime, but don't expect it in the near future. It requires understanding the concept, the code structure and many details to know how it works. Afterwards, I have to think about ways to hijack it and this needs to be implemented, tested and improved again and again. So please don't ask when it will be available - you will surely know when it is ready." Plz search xda before asking theses questions if you had you'd have found this http://forum.xda-developers.com/showthread.php?t=1574401
Sent from my Nexus 4 using Tapatalk
ART is still in early version so use Dalvik for next few months.
rishabl1d said:
ART is still in early version so use Dalvik for next few months.
Click to expand...
Click to collapse
it has been answered already, the op is just dumb enough to not read the sec post of xposed thread, witch says that it sets back to dalvik, so your answer is wrong, and you also are dumb enough to not read all posts//or u just wanna win more posts.
Is it that I will have to remove all the apps which does not support ART?I have greenify as well as titanium backup and removing xposed also did not help.What should I do?
I'm guessing you just uninstalled xposed without removing the framework... Sigh
Sent from my Nexus 4 using xda premium
Is it possible to make a flashable zip that can take a lollipop Rom and take all of the files and make them dalvik so theirs no compatability issues?
I don think there would be a way to., especially since Lollipop runs ART. But we will never know, unless someone tries to do this, but they would most likely have to change code around.
Sorry i'm not much help.
Dalvik and ART are two completely different things. Not only would the files need to be replaced, but the way apps run and the way the system calls on processes would have to be changed. Honestly, the system would never work if Dalvik ran on Lollipop. It would probably be easier to bring Lollipop features to KitKat lol.
davidhacks said:
Is it possible to make a flashable zip that can take a lollipop Rom and take all of the files and make them dalvik so theirs no compatability issues?
Click to expand...
Click to collapse
Why? The only negative impact I heard about from the transition from dalvik to art is that some old apps won't run, but I have lots of apps and have had not found any that won't work. What am I missing?
While Primary idea behind Project Treble allowing the OS layer to be updated independently - without relying on /vendor things (For starters/newbies https://www.xda-developers.com/project-treble-custom-rom-development/ )
Here at XDA we tinker around ROMs all the times. Irrespectively of ROM's stability, causal users always get stuck due to necessity to clean flash every time they want to try new ROM/new version of android
Dirty flash often creates conflicts with framework-res, System-Ui, etc etc such system apps data after a new ROM/Update and create unnecessary issues. Thus mostly considered as taboo. Whereas running Stock does not need to data wipe throughout device update lifecycle.
So, I would want discuss about the possibility of having /data modular to ROM as User App data is not going to change (Based on which root backup solutions like Titanium backup,etc work). This should enable the possibility of flashing any ROM, and User apps working smoothly on new ROM (just like device-specific blobs, etc in vender) unless major android version change is detected.
@ XDA Devs, Is this technically feasible?
Obviously its possible, i use this trick since last year.
In this trick, the app wont deleted, but, the app-data will erase.
Also everything inside/data (excluding media) erase.
But, the large sized /data/app will be intact.
Btw, it wont work, if u rollback to previous android version.
Only works within same version of multiple roms/ upgrading Android version
afridi.shahriar said:
Obviously its possible, i use this trick since last year.
In this trick, the app wont deleted, but, the app-data will erase.
Also everything inside/data (excluding media) erase.
But, the large sized /data/app will be intact.
Btw, it wont work, if u rollback to previous android version.
Only works within same version of multiple roms/ upgrading Android version
Click to expand...
Click to collapse
People are ok to lose app data if they want to roll back to previous versions of android. My context is reg. Project Treble which is only supported from Oreo..
Btw., Senior developers/tweakers pls think about this. Lets discuss if implementation of this is possible down our ROMs lane!!
arvindgr said:
People are ok to lose app data if they want to roll back to previous versions of android. My context is reg. Project Treble which is only supported from Oreo..
Btw., Senior developers/tweakers pls think about this. Lets discuss if implementation of this is possible down our ROMs lane!!
Click to expand...
Click to collapse
Hey. U don't need trebel/oreo to change ROM without deleting apps.apk, even i used this trick since......mmmm marshmallow 6.0.x
Is this referencing deleting /data/data/?
It works... But can have issues based on ART optimization...
Which is why the full wipe is recommended... Not for stability... But for troubleshooting
Sent from my PH-1 using Tapatalk
Maybe even just deleting /data/data for just the system apps, keeping the user app data in tact. Its definitely possible with a basic recovery script. Maybe we can look into that
rignfool said:
Is this referencing deleting /data/data/?
It works... But can have issues based on ART optimization...
Which is why the full wipe is recommended... Not for stability... But for troubleshooting
Click to expand...
Click to collapse
Thread is related to not deleting /data/data/ on ROM changes. Won't such ART Optimisation issues go off when cache is cleared?
This same is done on stock ROMs and even official Lineage OS updates don't require clean flash
tytydraco said:
Maybe even just deleting /data/data for just the system apps, keeping the user app data in tact. Its definitely possible with a basic recovery script. Maybe we can look into that
Click to expand...
Click to collapse
Yeah, when treble overcomes some major system partition shortfalls, /data shouldn't that hard.
Basically, this should ideally allow us switch between ROMs seemlessly...
I was able to do this about 3 years ago when I had an s3 mini, I had a custom rom available called Vibrant os but I wanted some apps to be pre-setup it included a data folder with data/app and data/data included along with data/system for wallpaper
took me a while and I had to find the folder permissions for each folder and do the set permissions command in the updater script but I was able to somewhat do this
I've taken the same code applied it but with set metadata changed to set perm
and I've reverted back to stock EMUI from resurrection remix project treble and all my apps have come across ( the data/data folder is next but atleast it is possible )
some google apps don't work if downgrading though
right now i'm copying data/app to my sdcard manually, wiping system, moving it back then doing my script
My goal is for the script to move data/app and data/data to the sd card, format data partition as f2fs, move data/app and data/data back then set the permissions
So basically, split /data/data into...
/data/data_system
/data/data_user
...?
I guess it's possible, but it would require changes at the ROM level. Maybe only framework, but possibly also in native code (e.g. zygote, not sure).
But... I don't think this really has anything to do with Treble.
CosmicDan said:
So basically, split /data/data into...
/data/data_system
/data/data_user
...?
I guess it's possible, but it would require changes at the ROM level. Maybe only framework, but possibly also in native code (e.g. zygote, not sure).
But... I don't think this really has anything to do with Treble.
Click to expand...
Click to collapse
i've managed to downgrade back from pixel experiece 8.1.0 to EMUI 8.0.0 and keep my apps ( data for the apps is tricky finding out the right read, write, execute permissions )
Livi-Tech said:
i've managed to downgrade back from pixel experiece 8.1.0 to EMUI 8.0.0 and keep my apps ( data for the apps is tricky finding out the right read, write, execute permissions )
Click to expand...
Click to collapse
It's not really, you just run restorecon command recursively on the tree - as long as file_contexts is intact then it will set permissions (and, more importantly, contexts) as they should be.