I have never rooted any of my Android devices because I've never really had any reason to. That and I was always nervous to do with my Droid Incredible even though I'm a computer guy.
However, I am considering rooting for this device because of some benefits I've read about such as:
1. Overclocking
2. Better battery life
3. Additional apps or functionality (I want to use Google Movies, Netflix, Hulu Plus, etc and I am guessing root might help get some of this sooner based on some of the other threads)
My concern is whether overclocking has any risk to the processor long term in the tab? For some reason, I seem to have something in my head from years back that overclocking computers/devices could cause processors to overheat or something. Maybe this is an old concern from when I was in college that was specific to PC hardware?
Also, aside from sticky threads, is there any thing on the wiki that talks a bit more about some of the apps used to manage ROMs and backups along with what is preferred and why? I read a good rooting guide thread in Android development forum but apps change all the time and I read different things in each thread that it can be hard to follow jumping in now.
If I missed a thread, feel free to point me to it.
Thanks.
Overclock always carries risks to hardware, especially without proper configuration. When overclocking you will use apps such as SetCPU or others, these apps typically have 'profiles' set up. On my LG G2x I have profiles set like:
Default 1.5GHz
Screen Off 400mhz
Battery Tempurate 48c Downclock to 800mhz
These settings will give you great performance, great battery life and a safety net assuming you leave your phone in direct heat. Sometimes if the battery gets too hot you'll damage your hardware, I've had this happen to my old Nexus One where I now have a very dark spot measuring about half an inch around on my display.
In consideration to rooted apps for Galaxy Tab... Hulu works without root by simply installing a modified Adobe Flash Player and adjusting your browser configuration to reflect a desktop user agent (You can easily find all this information using Google). Google Movies probably won't be available to rooted devices due to the agreement that Google signed with production companies, and whether root will allow you to run this application really depends on the way the content is delivered, however, I'm sure someone will figure it out.
Overclocking the Galaxy Tab probably will resemble the performance measures of other Tegra based devices. G2x can acheive 1.5GHz and Xoom 1.7GHz. Stability is really hit or miss as no two cpu's are created equal. I'm on my third Galaxy Tab and my third G2x and have not ran into an issue where I can't overclock to the speeds which kernel developers are building.
Edit: There is really only one overclock kernel available right now for the 10.1 and Pershoot is working hard to make it stable and powerful, the current 'preview' has quite a few stability issues.
So, hopefully this helps you out. Just an FYI though, really try and search. This has been repeated hundreds of times throughout various different forums. The general consensus is that rooting provides far too many benefits to be afraid of hurting your device, and so long as your are able to A. Unroot the phone for manufacture warranty B. Backup and restore using Nandroid, you will not have any issues that can't be resolved.
Heat is bad for electronics, and any time you increase the operating frequency or voltage of a microprocessor, you're going to be generating more heat. Modern hardware has thermal monitoring and throttling capabilities, and as such you're going to be able to simply fry your processor by pushing it too hard. However the additional stress is is accumulative and will shorten the life of your hardware.
That being said, I suspect that the operational life time of the chips in our tablets (and virtually any modern computer) is several orders of magnitude longer than their useful life time. I'm not entirely sure how long these processors last if operated at spec (it may be in a white paper somewhere), but I suspect it is on the order of many decades, if not centuries.
mesasone, true it will generate heat at full load but in all reality my G2x rarely throttles all the way up to 1.5GHz unless I manual set it to for benchmarking.
Thanks wesbalmer and mesasone. I've been reading threads all day for the last 6 hrs before posting but I'll search a bit more next time. This was helpful in reassuring me though.
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
mikeserv said:
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Entropy512 said:
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Click to expand...
Click to collapse
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
mikeserv said:
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Entropy512 said:
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Click to expand...
Click to collapse
Wow. Strong words. You consider PulseAudio an existential bane, huh? Can I ask what sound daemon you use instead? I suppose it's possible you do without. Though it seems OSS is entirely deprecated, ALSA can still provide minimal functionality without a user-space management daemon if necessary, but without some extensive and, at least to me, seemingly esoteric initial configurations, good luck handling even a lasting volume adjustment without root access (or be in the "sound' group, I suppose), and should you have occasion to simultaneously offer two applications sound privileges... Sorry, grinding my teeth again.
Anyway, I didn't much like PA at first either, but I wanna say my first encounter with it was Ubuntu 7.10 or so, or thereabouts. I've since adopted the greener pastures offerred by several other distributions, less brown anyway, but PulseAudio is a fairly static component of my sound system as configured by default by distro maintainers no matter where I wander. Even on systems I build up myself from very little, when PulseAudio is included it tends to be one the things I have to consider least as trouble goes. The plugin support is very extensive these days as well.
When PulseAudio is combined with Bluez for instance, it can emulate almost all of the headset profiles, to include a telecommunications headset, and can easily record from this stream or any other because every one of PA's sources can be easily multiplexed. It's fun, and very powerful. PA can do on cheap or even no dedicated hardware at all what Airplay only aspires to. And these days, it even makes it easy. It's a true sound server, and while it can be utilized simply enough with Android satellite clients if you set it to emulate Airplay, to serve a multi/unicast, and/or to emulate the DLNA protocol, even this impressive scope of functionality is much diminished when compared to two PA servers working in concert.
Other desktop alternatives do exist, of course. There's Jack, designed to provide low-latency, realtime audio rendering, but these days it seems it too seems to operate best, and is most often configured to do so by default, in conjunction with a PA daemon. And MPD of course, which I confess I have much interest in, but very little other incentive otherwise to actually try for myself. I don't actually known what it's capable of. Perhaps you do? I wonder, is it just, as is eponymously implied, a music player daemon? Or can it actually be extended to do the kinds of things I've come to expect of PA as hinted at above? I really should find out.
Anyway, if you haven't had a look at this, it might interest you: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
The author takes care to provide many impressive benchmarking results as proof of the worth of his efforts. If that sparks your interest, you'll find the Android port homepage here: http://www.freedesktop.org/wiki/Software/PulseAudio/Ports/Android/.
And try to remember that PulseAudio is a more mature and proven project than is Android itself, much less SoundFlinger, and each of these three could be said to have experienced some rather rocky starts.
As for the Bluez project being recently dropped from Android and its even more recent Android-focused development, I believe these things are likely just as related as they appear to be. I would have to dig deeper than scanning a few kernel changelogs to be sure, but as I understand it for about a year or two, Bluez has been undergoing a codebase overhaul. I expect that in such a scenario the Linux kernel's default Bluetooth stack would have to focus initial efforts on the Linux kernel's core x86 support, and especially providing ARM support would prove difficult due to its lack of a default firmware interface and handling the myriad hardware access mechanisms might just have been too much at the time. Again, these are my assumptions, but what has definitely happened recently is a concerted effort at full Android support. If my assumptions are correct, then probably the Bluez project just got caught up is all. In any case, the functionality Bluez provides, especially where networking transparency is concerned, is definitely superior. Find out for yourself if you'd like to know.
Surely I'll find out for myself soon, as I guess i'll be diving in after all. Never built Android from source before, which doesn't make much sense as I've had nothing but Android devices since my G1, every one of which, up to and including the Dream, was rooted and flashed with at least a replacement recovery pretty much on day one. I guess better late than never, though.
Back soon, I expect! Best wishes!
-Mike
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
*edit of this mistakenly resulted in double-post below*
Entropy512 said:
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
Click to expand...
Click to collapse
Maybe that's true, but if you asked me I'd probably lean the other way and say instead that Ubuntu is in too many places. Honestly, PA is really not complicated if you consider it a suite of core sound apps as opposed to a single, cohesive application. Probably my biggest gripe with Ubuntu's interfaces is that they often do the opposite, which is of course contrary to Unix principles, and in the process they tend to sort of opaque over simple and accessible modular designs.
I won't attempt to argue that PulseAudio is simple by design, as we both know I'd be certain to lose that argument, but it does offer a few lesser known interfaces you might find interesting. For instance, one of my favorite little tools is pacat. This does exactly what it sounds like; point it at one or more of PA's sources and it will concatenate their raw audio output into stdout at which point you are free to pipeline it as you would any other stream. Imagine you took pacat, perhaps also lz4, nc, and another little pipe-friendly PA tool called paplay directed at a PA sync on its system rather than a source, and combined them all into a pipeline. I hope in this you might begin to see some of PA's merits that perhaps you've missed before.
Also, there is pacmd, which is not nearly as straightforward as those others I've mentioned, but is far more capable and very well documented. It can do anything PA can do, really, and is fully scriptable.
I don't know which versions of Ubuntu you use, but those not on rolling releases may not yet have caught up to the PA update that implemented a PulseAudio-module-specific udev adaptation. Newer PA versions now pretty much auto-configure audio modules in the same way early user-space handles kernel-module loading. It's kinda cool, and almost an entirely hands-off process.
Anyway, I'm through proselytizing. I just thought I'd mention these things because they're the bits that I use when I want to do something with it.
EDIT:
Entropy512 said:
...because of my experiences with it, I will never personally put any effort into putting it into more places...
Click to expand...
Click to collapse
I looked again and noticed this. While I fully understand where you're coming from here, I thought I heard some French kid on YouTube say that this was not the sort of response that should be expected for OmniRom feature requests. He described a sort of democratically driven road map, and specifically he said that if a feature request was well enough supported by the users, then the developers would implement it even if they did not agree it should be done. Has this policy changed?
Of course I realize that youtube guy was probably talking about majority rule as opposed to a well-argued request, and that I'm only one person, but above you say you will never do this thing, without making any allowances for the possibility of a vote or poll or similar.
Like I say, I fully understand your position on this, as I, of course, do not intend to devote my own efforts to something like further Android fragmentation for instance, vote or no vote. I just wish to know what to expect here, and if maybe I missed something.
-Mike
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients - All apps would have to be presented with something that is "audioflinger-like" which didn't offer the extra features offered to clients. Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Entropy512 said:
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Click to expand...
Click to collapse
Wow, man! Thanks very much indeed for replying with honesty and humility. I'm very pleased that I didn't, or at least I hope I did not. Even if you had said otherwise I would have fully understood, of course, but as it is, I'm also very impressed. I like discussion. Thanks, man.
Two questions: what's yamahell? And, because you say you've worked with it, can you tell me about AudioFlinger or whatever it is and maybe why the status quo is desirable? I thought it was a problem. I'm asking these things for my own edification and because I think I'm gonna try something to do with a PA replacement.
While I agree PA may be overkill, I really don't believe pulse has to be applied monolithically, you know? It's already designed to work with modules, so maybe a subset would be sufficient. Clients only communicate with libpulse.so for the most part, for example. And for the past few months (on an upstream system) PA and Bz have been working really well together. So I'll try it, maybe, after you tell your horror stories and I can judge for myself.
-Mike
-
Entropy512 said:
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients...
Click to expand...
Click to collapse
I assume you mean the first one, the blog on the initial port? Well, I believe that may have changed since then. The actual port homepage at freedesktop.org (the second link I provided) says this:
Code:
...[T]ested on Samsung/Google Galaxy Nexus as ... reference implementation... [P]ort fairly straight-forward for ... devices with ALSA support.
Various bits of functionality are available, and this is a moving target. The following are tested at the time of writing this section:
Audio playback for most apps using native Android APIs
Volume control
Switching of outputs depending on the device plugged in (headphones, headset)
To Be Done
The following pieces are either partially or not at all implemented
Audio playback API completeness: infrequently-used bits of the API (loops, markers, etc.) are not implemented
***BIG ONE*** Calls: this is work-in-progress, but needs to be cleaned and merged
Policy: initial implementations of volumes and port switching are done. There are probably a lot of bits of policy that still need to be implemented for us to have feature/bug-parity with standard Android.
Audio record API: can be implemented fairly easily like the playback API was
***NOT CLEAR ON THIS*** Audio effects API (we don't support this in PulseAudio at the moment)
Entropy512 said:
Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
Click to expand...
Click to collapse
Something tells me this is a statement I should be able to fully comprehend before getting neck deep...
Entropy512 said:
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Click to expand...
Click to collapse
It doesn't look so huge to me, as much is already done, I think. But then I've to hear your horror stories so I will reserve judgement.
Entropy512 said:
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Click to expand...
Click to collapse
Yes, that article was written then, but the freedesktop.org homepage was created March of this year. I suspect some changes have accumulated along the way, and because PA is an actively developed high-profile application hosted and backed by RedHat, I expect that website landing page would be removed soon after it became irrelevant. I will, of course, reach out to the maintainers at that end as well for advice.
But... that's kind of the point... less redundancy, you know? Less fragmentation? No need for separate groups for thisnkind of stuff. I just thought that was inline with omni ideals. Is there another way that you know of that could as easily bring a like convergence of functionality with other Linux systems? I just wanted to effect something along those lines and I thought omni sounded like a place worth starting.
Also, I want those things.
-Mike
P.S. This is the git repo described in the .XML repo definition for the PA build-code at freedesktop.org: http://cgit.collabora.com/git/
You can see the android specific PA packages are being worked on, and very recently. Also, ALSA is seeing somewhat recent dev work as well.
EDIT: This may not even be quite as difficult as i initially assumed.You can also see at the following git repo that a commit was made to master referencing 'mako' 5 weeks ago.
http://cgit.collabora.com/git/android/platform/external/collabora/pulseaudio-android.git/
yamahell - the hell that was working with the Yamaha MC1N2 codec seen on many Galaxy S2 family devices.
Poorly documented, kernel code written by a member of a primitive tribe with no concept of zero, Samsung's blob HALs doing all sorts of unpredictable crap requiring workaorunds and hacks...
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Entropy512 said:
...no concept of zero...
Click to expand...
Click to collapse
....should I?
Entropy512 said:
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Click to expand...
Click to collapse
This makes very good sense. While I think the PA 4.0 changeligs from July or so may acknowledge this lack they also seem to indicate it's been addressed. Would you mind looking? Not positive I'm reading it right.
-Mike
Here is a [BOUNTY] you will not want to miss out on. First complete set of instructions on how to totally jailbreak the HD8 2020 or HD8 2022 gets a cool $1000 cash once the instructions are completely verified. And another sum of equal or greater value upon full testing.
Here are the details:
The device should have no remnants of the old OS visible to the user. The interface should look as close to stock Android as possible. Setup menu, some file manager application, and a few other applications should be available if necessary. There should be no ability to side load other apps.
I am looking to push one app onto the device, which is being developed. That application is a specialized audio player taking advantage of the very decent audio properties of the HD8 2020 or 2022. The app will take a LOT of the processing power so all radios will be turned off and fixed to be non-functional. USB will work and stay in debug mode for updates and additional data xfers. Graphics will be used at a minimum. Much of the compute power of the device will be tasked with calculations and playing audio. Some of which will be calculated on the fly. Please reply if you have any further questions.
There may be other paid design/programming activities associated with this project.
I hope this is a joke.
Rortiz2 said:
I hope this is a joke.
Click to expand...
Click to collapse
What part is unclear? This is not a joke.
The purpose of this request is to limit the functionality of the tablet for safety of the individual using my product. Taxing the processor to do other things will take away from all of the work the processor must do maintaining the functionality of the device plugged into the USB C port that I am designing. It is not yet clear that the device needs to be rooted. At least the GUI menu needs to be closer to Android stock. I really presume that current work is fairly close to what I will need except for the following: Turn off radios permanently, replace the menus with something better than currently offered, and prevent loading other software.
Current setup that I have makes some noise, (popping) on the audio output that is not so good.
rhandel said:
What part is unclear? This is not a joke.
The purpose of this request is to limit the functionality of the tablet for safety of the individual using my product. Taxing the processor to do other things will take away from all of the work the processor must do maintaining the functionality of the device plugged into the USB C port that I am designing. It is not yet clear that the device needs to be rooted. At least the GUI menu needs to be closer to Android stock. I really presume that current work is fairly close to what I will need except for the following: Turn off radios permanently, replace the menus with something better than currently offered, and prevent loading other software.
Current setup that I have makes some noise, (popping) on the audio output that is not so good.
Click to expand...
Click to collapse
I'm sorry to be the one to burst your bubble of illusion but I'm afraid that if all you want to do requires root, you can start by buying another device (and make sure it's not from Amazon).
Your idea sounds cool, stock Android and forget about FireOS, the usual dream of Amazon Fire users. However, this is not possible in recent generations since Amazon made sure to close all the backdoors that helped us unlock older generation tablets. This includes patching the LK vulnerability (amonet), disabling bootrom mode (with efuses), always updating security patches (Amazon has always been a stickler for this), and among other very extreme security measures.
In short, the devices you are talking about are not unlockable and I really doubt that in the future they will be. My personal recommendation; try to find one of the early Amazon Fire HD10 2019s, which can be temporarily unlocked and have several ROMs based on AOSP (LineageOS, ArrowOS).
Thank you for the impassioned recommendations. I get that, and now have a better appreciation of the task.
Do you have any recommendations for newer hardware that can fill the bill? This project requires octicore hardware or better because of the need for speed/performance of newer processors to do the heavy lifting. I have had several other Android devices (off brand Chinese attempts at hardware), that are too under powered for the purpose and have too many bugs to be considered.
Here are the basics: I am looking to push one app onto the device, which is being developed. That application is a specialized audio player taking advantage of the very decent audio properties the device. The app will take a LOT of the processing power so all radios will be turned off and fixed to be non-functional. USB will work and stay in debug mode for updates and additional data xfers. Graphics will be used at a minimum. Much of the compute power of the device will be tasked with calculations and playing audio. Some of which will be calculated on the fly.
All of this can be done on an RPi 4 but I am looking to shave costs off of the device. I don't NEED android. It's a means to an end. Development costs are not the issue but ongoing costs adding to product cost are.
Rortiz2 said:
Your idea sounds cool, stock Android and forget about FireOS, the usual dream of Amazon Fire users. However, this is not possible in recent generations since Amazon made sure to close all the backdoors that helped us unlock older generation tablets. This includes patching the LK vulnerability (amonet), disabling bootrom mode (with efuses), always updating security patches (Amazon has always been a stickler for this), and among other very extreme security measures.
In short, the devices you are talking about are not unlockable and I really doubt that in the future they will be. My personal recommendation; try to find one of the early Amazon Fire HD10 2019s, which can be temporarily unlocked and have several ROMs based on AOSP (LineageOS, ArrowOS).
Click to expand...
Click to collapse
Can we put this information somewhere easy to find for people (like me) searching for ways to "free" the newer generations? I have spent quite some time to find information about rooting possibilities for the 12th generation of Fire 8 HD and not been able to find it. But here, in a Thread certainly not meant fo me, i found them
MarvinGS said:
Can we put this information somewhere easy to find for people (like me) searching for ways to "free" the newer generations? I have spent quite some time to find information about rooting possibilities for the 12th generation of Fire 8 HD and not been able to find it. But here, in a Thread certainly not meant fo me, i found them
Click to expand...
Click to collapse
MarvinGS,
The bottom line is that the prospects are fewer and fewer because of the tightening down of the Android system. And the very custom hardware used in many new devices. It is NOT as trivial as it used to be. And intentionally so. Amazon has a vested interest in keeping things from people like you and I.
I am looking for cheap hardware to make a larger project and will probably go with dedicated hardware to get the features that I need. I was merely looking for the video and some light computing to be done by Android. The devices still don't have enough power to do what I need them to do.
RAH