Let me start by saying yes I read the forum rules for the Paid Software group and as far as I can tell I'm posting in the correct spot. I don't meet the 100+ post criteria but I also am not selling an application. If this belongs elsewhere please move it, don't delete
Basically what I'm looking for is some constructive critisim and feedback. I'm a software development major wanting to someday make a career of Android development, but as a student am constantly needing to partake in projects. For side work for the last year or so I have been doing Android rooting, flashing and modification via CL. One big issue I immedietly noticed was my scope of work. I could reach a much larger audience if travel wasn't part of the equation. This gave me an idea..
Most root methods are simply a few scripts ran in sequence, with a possible reboot or two in the process. A lot of that can even be handled by writing a single script to run each file in order, with a response wait while rebooting occurs.
I'm considering hosting a website on which users can access my server, and, after selecting their device, root it with a single click. Keep in mind I've successfully rooted over 70 phones, with no failures, and have been tediously keep track of the easiest, least risky exploits and methods. Of course rooting (like always) would be at the users liability.
Any ideas or feedback would be greatly appriciated. Android is, and poised to continue, dominating the smartphone market. I feel that a resource like this would literally be invaluable to the community. If I continue to stick with this it will probably be going on KickStarter soon.
bummmpity bumpage
Evo OTA 4.24.651.1
Have you been able to root the HTC Evo 4G with the 4.24.651.1 update?
Many of you are going to know all this, and many know far better than I. Please, those that do, please step in and correct my information if I make any mistakes.
I see the word stable thrown around a lot - "Is this ROM stable", "stable release", etc.
I want to attempt to pin down a definition when in use for regular conversation, and I also want to address that there is one use of the word that is clearly defined and cannot be used lightly.
First, in the development/open source world, the vast majority of projects you will see are in beta or sometimes even alpha. This means that it's still in some sort of testing phase, and there are usually some bugs that need to be ironed out before it's termed a "finished product". By the very nature of software and developers' desire to be honest, it's quite common that there are some pieces of software that will never leave beta(and some even used in a corporate production environment. "beta" is not a death sentence and doesn't mean there's something fatally flawed). There is always more work to be done, a bug here, something to smooth out there, something that needs to be optimized, etc. A developer can not be satisfied to release a final version. That being said, it does happen. Once it reaches past beta, it often gets promoted to a "release candidate".
A release candidate, or RC, means that they are fairly satisfied that bugs are taken care of, and that they are PRETTY sure there's no major flaw lurking in the depths waiting for the perfect moment to rise and bring down death and destruction upon any innocent fool who crosses its path. This is the final step leading up to that coveted and rare specimen - the :victory:Stable Release.:victory:
Once the release candidate has gone through rigorous testing by developers, users, testers, etc, it can finally become a stable release. It's a big risk to label something as a stable release. This is the developer giving you their word and staking their reputation to say "there are no bugs in this piece of software. It is being released as a final version and will not cause you any trouble".
I beg you to correct me if I'm wrong, but I don't believe there are stable releases for any any ROM for the MT4GS. Once again, this is very common in the development world, and not just for phones. Just take a look at the number of projects on slashdot that are widely used by thousands of people with no trouble - much of them sitting in beta or even alpha.
Now is where we run into some ambiguity using the term. At a passing glance, and certainly to the uninformed, seeing that software isn't "stable" will naturally and intuitively lead one to believe it must be somehow unstable. Given the nature of open source and development, we know that this isn't necessarily the case. There may be something very minor that only comes up in certain situations, the developer may still feel that there hasn't been enough testing to rule out any bugs, or there may be no bugs at all but the developer is not yet satisfied with the completeness, speed, or number of features.
Now, I would like to address how the word is used in conversation or when asking questions about a ROM. Stability itself, is absolutely very important, with good reason, to a vast majority of people who own a mobile phone. This is often their only source of communication and is required for work, for emergencies, and for generally keeping in contact. If the phone fails to function in a manner that keeps the user reliably connected to their web resources as well as phone, email and messaging communication, there could very well be disastrous results. Therefore, asking if the rom is stable is very valid and relevant, but due to the fact that the word stable can have such an ambiguous definition, and is also a term for a particular stage in development, communication can break down pretty quickly between parties when the term starts getting tossed around.
The device I had previously was a Motorola Droid 1(OG Droid, Sholes, etc.). This phone had a huge and extremely active development community on many different websites. Many devs still hold the moto droid in a special place in their hearts for how hackable it was, the power it had for a device at the time of its release, and the massive userbase ranging from those with no technical ability at all to some of the best hackers ever to work on Android. This device truly represented the renaissance, if not the birth, of custom development for android devices.One thing that was extremely common across almost any ROM or kernel you could put on that phone, however, was a risk of "instability". In this case, this usually meant that the phone would randomly reboot, especially when doing something particularly tasking on the cpu(navigation was a particularly common culprit). In extreme cases, it would reboot and then go into soft bootloops once, twice, even five times. This happened more often with overclocked kernels, and most people had to look for multiple kernels and setcpu settings that would give them a balance between speed and stability. It took some trying and some tweaking. Most people would eventually get a setup that was solid. Even with a "rock solid" kernel and ROM setup, there were very few who NEVER experienced a random reboot when running a custom ROM/kernel. It was just something that happened. The other major issue people saw were force closes of apps. These were extremely common as well, but usually addressed more easily. Your setup was considered stable if you were confident that you could do all of your phone's functions without getting FC's and you weren't going to get a reboot 99% of the time. You could rely on it not to do anything unexpected.
I have, admittedly, not tested every ROM that exists for the MT4GS. I probably haven't tested half of them. I have however, tested most of the later releases with the exception of XMC's Jellybean. What I have found, however, is that out of all the ROMs I have tested for this device, each and every one one of them has met my personal definition of stable. I've never seen a random reboot on the MT4GS. If I see a FC, it's because I failed to clear data and cache before flashing something, forgot to flash or flashed the wrong version of gapps, or I'm trying to get something working that wasn't included in the ROM. It's for this reason that I really don't know how to respond accurately when someone asks something like "what's the most stable ROM for this phone?" or "I saw this particular ROM, can anyone tell me how stable it is?"
So I have two requests. The first is for anyone who cares to read all of this and answer. I'd like to ask you, if you are asking about how "stable" a rom is, what do you mean? Are you asking about whether it has bugs? They all have a bug list of what's working and what's not. Are you asking about whether it has a certain feature fully working? Once again, that's in the works/ doesn't work info usually including in the first post about the ROM.
Request 1:
Answer me this - What does "stable" mean to you?
Request 2:
When considering or just looking for info on a ROM and you have a question about this or that, be specific. If I've checked into a ROM, I very well might have an answer for you. If you just ask whether or not it's "stable", I don't know what you're asking
I can see where you're coming from.
Personally, stability for me is a rom that works well enough where the phone isn't bugged out entirely (has over 80% of the phone's default settings working such as calling or getting into e-mail, etc.).
In general, there are others who request too much and want utter perfection. No rom is ever going to be perfect, regardless of the stage of the rom (alpha, beta, release candidate).
Sent from my myTouch_4G_Slide using xda premium
To me a "stable" ROM is one where all of the phone's functions work as designed, meaning the camera, bluetooth, wifi, keyboard, etc. all function without having to do anything extraordinary. Also, the ROM itself doesn't require extraordinary measures to perform common functions and doesn't FC or random-boot. I can accept a few minor glitches, even stock ROMs from HTC have those. But, for my overall needs, I currently run only a stock-based ROM because I absolutely need the stability and all functions (especially the camera and stable wifi). This is my ONLY phone, I don't have another mobile nor a landline, so stability is #1 priority.
I've waited a long time for your post.
...and I agree with everything you've said thus far in principle.
The concept of stable is in and of itself a dynamic thing in a place like this under the many varied intentions of the people developing anything here.
Consider that in many cases things are made as examples, or proof of concept. Such things may be deemed stable by the creator on the particular proof, yet be unstable for other uses.
In many cases, such things are outlined by the developer and the bounds determining stability vary widely from project to project, and developer to developer.
In the retail world of say, phone sales, and the manufacturers guarantee against defects, the business world is held to a certain threshold of accountability for providing a working product.
For us here, there is no money involved - people aren't paying for a product, and so lose at most up time with the device while it gets sorted out. The total loss of the device itself, as in hard brick, due not to user error but to developer error is where I would say the minimum standard of stability lies.
That bears, in my eyes, the closest relation to the business world standard of a manufacturers guarantee against defects. Buggy software, and the clarification thereof being the topic to pick apart - i'd like to get a consensus of how many other people feel that simply not hard-bricking the device due to developer error is the complete polar opposite of:
karri0n said:
...
that coveted and rare specimen - the :victory:Stable Release.:victory:
...
Click to expand...
Click to collapse
...where the quote is in-context of being a final, finished product.
The minimum threshold being the easier end of the debate to reach agreement on and build our understanding from.
....
So how does a developer get to stable projects?
Drawing a parallel from the manufacturing industry, the answer is quality control.
If your business is running assembly lines of product, at the end of the line needs to be a certain amount of quality control before shipping. Else the product could vary widely in stated ability and function. A shop with little to no quality control could be one equivalent to an unstable release.
This points us in a direction in the determination of stability - the comparable equivalent from our point of view is testing. You have to test your product (project) before sharing, else you don't know if it will work right.
Unlike an assembly line where testing is done on a random small sampling of pieces, a developer must rigorously test and retest the project (product) to ensure stability and reliability of function.
Of course, this begs the question of the standards involved in testing.
Ever seen this movie? The Pentagon Wars
It's a riot - but also illustrates the importance of standards in testing.
To us one way, arguably the most important way, is developing a consistent method of testing to properly evaluate the desired results.
Consider my first project of involvement at XDA was in understanding the differences in MicroSD cards for running CM7 booted off the Sdcard and not the internal memory of a device. Some cards were downright buttery smooth and amazing, other cards were downright impossible to work with. They were directly found to be the culprit of force closes, if it could be run at all.
Once we determined that there was a specific brand that could be consistently counted on to perform to spec (through a massive posting of speed test results by ever so many members of the community!!! :highfive: ) - I set about trying to determine how accurate the posted information was.
This thread: A Closer Look At MicroSD and Reader Speed
...was primarily established to determine how much the type of card reader used skewed the testing results.
Granted, i'm biased based on having written the article, but I would consider that project to be an example of rigorous standards of testing for a particular piece of information.
I use this example to make the point of stability. In this case it directly equates to validity of results. By recording all of the data, publishing all of the data, people can point out where my math may be wrong if i've made a mistake based on calculations of the raw published data.
( just like people can offer suggestions on published open-source code )
...or incorporate the results into further testing of their own - based on the validity ( stability ) of the data.
Another example of what I would consider trying to achieve a "stable release" of an answer to a question through rigorous testing: My first real doubleshot contribution.
So I put forth those two projects of mine to illustrate what I consider stable releases of information. If not, explain why?
So a stable release not only is important from a user perspective, but also from an open-source developers perspective.
How solid is the code(knowledge, information, etc...) being built on, if a coding (or other...) project? Is the code you are nudging in a direction you think would be interesting buggy to start with?
Is your own new code buggy to start with?
Do you just throw it out there and keep working with it until it works? Do you take the time to ensure it works to the best of your ability before releasing?
Both are very valid approaches - some radical concepts are seen to reality much more quickly because the incomplete thought was tossed into cyberspace to grow to maturity.
The developers ability to relay the type of project it is, and the expectations of use can in fact create the business world equivalent of 'buyer beware' in the context of placing the onus of determining stability on the end user.
Because stability really depends on perspective.
Saying that something is a daily-driver, i'd use it everyday kind of thing is most akin to the:
karri0n said:
...
that coveted and rare specimen - the :victory:Stable Release.:victory:
...
Click to expand...
Click to collapse
...that we are trying to define as the upper end of finished.
There again though, this varies based on perspective.
Pretend a large enough user base decided they didn't care about not having any bluetooth ability. Along come some ROMs that don't include that function. They state such, and otherwise have bugs on a very individual user level basis, if at all.
To that user-base, those ROMs are stable. What about you? You lose your bluetooth headset and can't do without that. Being as bluetooth is a functional piece of equipment within the device, any ROM without it is technically unstable. Can we agree with this?
Stability can also be defined, at least in part, by a developers ability and attention to resolve issues "Immediately, if not sooner". This becomes a determination of stability based on the developers ability and timeliness in resolving issues.
Otherwise stable software can become corrupted through interaction with other code that doesn't agree with it. There are a lot of apps out there, and Android is an environment allowing for much more freedom then the app store.
Due to the increase of involvement of chaos theory throughout the Android environment, I'd put forth that the stability of any software is in part tied to the developers attention to unforeseen interactions due to the scope of Android at large.
Here again, is another example - by this definition:
"Bulletproof was more stable when I was actively working on it - before I had to take a leave of absence." During that leave time, the ROM is less stable then it was before, because any new problems aren't attended to.
But we can say that not only the level of attention, but the quality of that attention is important too.
A consistent voluntary lack of desire in chasing down new bugs and fixing them could be seen as the equivalent of that crappy customer service call. Maybe you just exceeded the developers interest in the project, and to that developer it was stable for it's intentions at the time, and has moved on.
From one perspective, the project was completely stable. From another, quite the opposite.
There again, you have developers moving on to other phones, or using projects as stepping stones to other goals. We would need to agree to be able to define something as "stable to a point" if the project was brought so far forwards before the developer left it behind for others to build on.
Sometimes while building bulletproof I threw out stability and claims/remarks thereof in order to challenge the community to define what it was to me.
In the end, stability to me correlates to the endless anal attention to detail - on all fronts. To write clean code, to properly wipe and prepare the device, and the burden of utilizing a stable product rests with both the producer and the user - even if the only user is the producer.
Given the many facets of 'Stability' in trying to define it - how accurately can we do so?
I look forward to the postings on this thought experiment.
How big is big?
I'd bet that the word "stable" means something slightly different to nearly everyone. As an active user that tinkers with their installation a lot "stable" means no more than a 1 problem that requires a reset every week or two. Different usage would mean different definitions. Another user on my account that primarily uses his smart phone for calls won't tolerate more than 1 problem a month and for him, even that is frustrating. For emergency personnel any problem that prevents phone usage would be way too many.
The word also has different meanings for different products. I wouldn't consider a router that has more than 1 or 2 problems a year stable. Commercial communications equipment I've worked with was deployed in environments where it was expected to run at least 2 years without a problem. It was so well designed that occasionally it would run 5 or more years and the end users would forget where it was located and sometimes even that it existed at all.
I guess language just sucks for this type of thing.
All I want is a sense-less ROM that doesn't have random reboots and I'll stick with this phone for another year. As it is now I can't freaking stand it. That's with a totally fresh wipe and install of Virtuous Inquisition. I just don't buy into the idea that these phones aren't meant to download all the apps and games we can fit off the play store (not that I do... I HAVE in the past but I've barely reinstalled anything since my most recent wipe). The idea that installing things is going to lead to issues that aren't the ROMs fault is crazy. The stock ROM doesn't have these issues with my apps being installed. I only rooted to get rid of that dumb genius button (and getting rid of sense was the icing on the cake although not totally necessary).
"Stable" should refer to a ROM that works completely fine except for 2-4 functions that are not essential to smartphone daily function.
"Stable" unfortunately refers to a ROM that boots around here.
Sent from my HTC MyTouch 4G Slide using xda premium
polarbearmc said:
All I want is a sense-less ROM that doesn't have random reboots and I'll stick with this phone for another year. As it is now I can't freaking stand it. That's with a totally fresh wipe and install of Virtuous Inquisition. I just don't buy into the idea that these phones aren't meant to download all the apps and games we can fit off the play store (not that I do... I HAVE in the past but I've barely reinstalled anything since my most recent wipe). The idea that installing things is going to lead to issues that aren't the ROMs fault is crazy. The stock ROM doesn't have these issues with my apps being installed. I only rooted to get rid of that dumb genius button (and getting rid of sense was the icing on the cake although not totally necessary).
Click to expand...
Click to collapse
I can't say I've seen any problems like you are describing. I only used Vinq for a very short time, before I realized that wifi calling didn't work on it. CM9 a5 does not have any random reboots and has more features than Vinq working. That being said, I haven't heard of anyone facng random reboots using Vinq. if I had to guess, I would say it's related to the way Vinq tries to patch some elements of Sense and some elements of AOSP together, and they just don't get along. If it were me, I would move to cm9. I don't like sense's remnants tainting up my device, especially if they're going to lead to problems. the ONLY exception to this is the stock DoubleShot camera I would enjoy having that, but not if it meant that I had to run sense libs and it started causing conflicts with other parts of my AOSP.
Perhaps upon reading that, you call to mind Thomas Jefferson pulling out his Android to thwart impeding forces. I actually like that idea, but I know that the time in which John Locke wrote the contributing phrase was much different than today. It was a time of change and also a time when people realized their full potential to make a difference. In the spirit of our Founding Fathers, and in an exercise of my own Personal Liberties, I have started a petition to require cell phone carriers to allow bootloader unlock on any Android device that is not under contract or subsidy. Many of you will know immediately what this means, and the exponential benefits of such a law. Many of you will flip to the next activity complacently believing this does not affect you. If you do not understand, I wish to enlighten you as to how this affects each and every Android user in the world. Signing the petition takes only a few moments of your time and adds to the greater good of our technology and innovation as a Nation.
So what exactly does this “Bootloader Unlock” thing mean?
Well, that is a great question. Most simply put, according to Motorla’s website, “bootloader is a little bit of code that tells your device's operating system how to boot up”. That does not mean much to the average user, I am sure. What it means in my own words is it is a piece of code that dictates what I can and cannot do, in terms of software modification, to my own personal Android device. On my wireless provider whom I will call Big Red, their requirement is that OEMs (Original Equipment Manufacturers, or simply phone makers) lock this bit of code to prevent modification by the end-user or customer. I am certain, to those that do not wish to modify their devices, this sounds like a good fail-safe to avoid breaking their devices. I am also certain that to those like myself, those who have the experience and knowledge to do things like flash custom firmware or software and modify our devices to suit our own personal taste and needs, this is a huge roadblock and an impediment on what we can do with our own personal property and how it can be improved. In order to modify system files as the user sees fit, a thing called Root is required. Root is, most simply privileged access to a phones file system. A locked bootloader means that in order to gain “Root” access, a security exploit must be found and exploited in order to modify system files. These exploits are literally holes that must be (and typically are) patched in software updates sent out by the service providers or manufacturers to protect the end-user. While the efforts of the security experts are always going to be required to keep us safe and updated, I personally do not want to rely on someone to hack the software so it can be modified. This should be an inherent ability of any user who does not have a subsidy or contract obligation. I also feel that any device that can be updated by the user allows the people who develop for Android to Innovate and push our technology farther forward. When manufacturers are required to lock down a device, ultimately, the user is the one who loses. My first Android device, the Droid 1 or A855 ran an under-volted overclocked kernel (simply another piece of code that tells a device how to boot and how to run its processor among other things) that ran 1.7ghz on it’s ~600mhz processor. I used that phone at least twice as long as I would have if it hadn’t been bootloader unlocked. Also, on the note of the OG Droid, I can say that this was the phone that helped Verizon to compete with the Iphone, bolstering the customer base and creating mass knowledge of the Andoid platform. This was done with a bootloader-unlocked device. It seems that once the market was realized, bootloader locking became the normative. The Droid line has been bootloader-locked ever since. There are several examples of the same hardware being sold, under different names, with the bootloader-unlockable right out of the box. The most recent example of this is the Motorola xt1250, or Moto Maxx (US CDMA). The international version of the same phone, the xt1225 is also bootloader-unlockable. All three are known as the Quark. They are identical in hardware aside from exteriors. Big Red required their version to have the bootloader locked. There is no way to have it unlocked for now.
So Why Would I Want to Sign This Petition?
Honestly, you may not care about Android at all. You could conceivably have never been interested, and care less. However, the technology available to you today is available because of innovations and advancements that have been made across a wide technological array of development. Android is no different. Love that Halo or Heads Up inspired feature ____ manufacturer just put on your new phone? People who develop are to be thanked. The possibilities are endless for what can be done and applied across many platforms. The future of mobile technology can be greatly advanced by creating open access for all who are inclined.
Catharsis
Okay, I admit it. It is really, really unlikely our politicians actually act upon this petition, even if 100,000 signatures are reached. As much as I like to think our law should “fix” things that are wrong, I can agree with one of my favorite developers from back in the day, @adrenalyne, when he said [government typically does not, and should not interfere with private business.] I can agree with that on the same grounds by which I feel we should be granted bootloader unlock on…if and only, if, no one’s rights are infringed upon. I feel it is all of our right to do what we please with our own personal property. There was a great analogy given on XDA Developers forum in the bounty thread where this all started by @Wynnded In essence, it said the carrier provides the highway, the OEM provides the device, but it is the carrier’s highway, so if the carrier requires the OEM to lock it down so be it. Personally, I feel that if the carrier has a highway, it is a toll-road, as I pay for my service. I purchase my vehicle outright, so if I want to modify it, and I pay for my vehicle, making no obligation to said toll operator, it is not within their range of rights to tell me I cannot modify my vehicle in the way I see fit. Thank you for your time. –kitcostantino @ medicbeard on twitter #unlockthedroids
https://petitions.whitehouse.gov/pe...e-not-subsized-or-attatched-contract/QfTmsspy
Original thread:
http://forum.xda-developers.com/dro...unlock-bootloader-root-turbo-t2927958/page115
Sources:
https://motorola-global-portal.custhelp.com/app/standalone/bootloader/unlock-your-device-a
http://en.wikipedia.org/wiki/Rooting_(Android_OS)
I ask for no donations, nor anything else. Simply share this if you feel so compelled. Really, it hurts nothing even if you don’t.
#unlockthedroids
I know xposed does not exist for the Verizon version of our galaxy s6 and rooting is not possible for vzw phones running 5.1.1. Im wondering if there is any way or anyone who could develop a module for any of us stuck on rooted 5.0.2 or if there's an issue blocking it? Reason asking.... It was a great tool and I think we might be stuck without root for a long time.....
I, like many here, have the same question. If you haven't seen this post http://forum.xda-developers.com/showpost.php?p=62884922&postcount=1073 it has what I read as descriptions of some of the more technical challenges to meet regarding Xposed. Additional descriptions can be found by this post by rovo89 http://forum.xda-developers.com/showpost.php?p=58949255&postcount=3 I interpret the two problems as described by @wanam in the following way: (Please note that while I am an engineer I am not a software engineer or developer so I apologize for any inaccuracies of my understanding)
Lack of a unified ART by Samsung for 5.0 - This sounds to me like an solvable problem for those with the technical ability as @arter97 but an INCREDIBLE amount of work. Given my professional experiences and the fact that usually when I'm asked to estimate the effort required to accomplish something, it is greater than what the requester expects; In this case I'm not willing to hazard a guess, especially since these folks tend do this as more of a hobby and are either students or have other jobs to pay the bills. I always hope for, but never expect, further work because of this.
Compressed Odexes - This seems in some ways more significant to me and my understanding is results in needing a deodexed ROM, which is doable but Custom ROM = Trip Knox.
The whole thing makes me want to become a proper software guy and try my hand at it myself, but I should probably get back to the lab and do some research. At this point, the most hopeful path may just be waiting for 6.0 and crossing our fingers that there are enough changes that one of them allows a root exploit to slip through for us.
I haven't said anything anyone else hasn't already, but I had spent some time running through these forums in search of understanding of all the above and thought given your post, maybe enough other people have the same questions that there would be value in providing all the links to the info in a centralized place.
- JasonVaritekMVP
JasonVaritekMVP said:
I, like many here, have the same question. If you haven't seen this post http://forum.xda-developers.com/showpost.php?p=62884922&postcount=1073 it has what I read as descriptions of some of the more technical challenges to meet regarding Xposed. Additional descriptions can be found by this post by rovo89 http://forum.xda-developers.com/showpost.php?p=58949255&postcount=3 I interpret the two problems as described by @wanam in the following way: (Please note that while I am an engineer I am not a software engineer or developer so I apologize for any inaccuracies of my understanding)
Lack of a unified ART by Samsung for 5.0 - This sounds to me like an solvable problem for those with the technical ability as @arter97 but an INCREDIBLE amount of work. Given my professional experiences and the fact that usually when I'm asked to estimate the effort required to accomplish something, it is greater than what the requester expects; In this case I'm not willing to hazard a guess, especially since these folks tend do this as more of a hobby and are either students or have other jobs to pay the bills. I always hope for, but never expect, further work because of this.
Compressed Odexes - This seems in some ways more significant to me and my understanding is results in needing a deodexed ROM, which is doable but Custom ROM = Trip Knox.
The whole thing makes me want to become a proper software guy and try my hand at it myself, but I should probably get back to the lab and do some research. At this point, the most hopeful path may just be waiting for 6.0 and crossing our fingers that there are enough changes that one of them allows a root exploit to slip through for us.
I haven't said anything anyone else hasn't already, but I had spent some time running through these forums in search of understanding of all the above and thought given your post, maybe enough other people have the same questions that there would be value in providing all the links to the info in a centralized place.
- JasonVaritekMVP
Click to expand...
Click to collapse
The second point concerning XZ compression is now supported on my latest unofficial Xposed for 5.1.1, it should be the same for 5.0 FWs.
Sent from my SM-G920F using Tapatalk
So no xposed? What's the final answer here
Most other people have very unrootable phones (I know us G900A-s do), and this Quadrooter exploit is present on multiple devices. What if we started a bounty to encourage development of this exploit, and whoever makes a working root first gets the payout? I'd be willing to contribute at least $20.
well, since it spans on so many devices and the driver seems to be the same, it would only require minor tweaks for each device. So any working code for one device can be applied to almost all of them. So in effect, all you have to do here is to compile a list of already existing bounties for all the pending devices and that will be the pool the dev for the exploit will get
this is a very good idea and needs to happen asap. my phone is terribly bloated and i cannot get root. ZTE Z988. Ive tried everything i can think of to get it rooted and this quadroot exploit looks like the best way in