Related
How come they got Android 2.3 on the iphone but noone can get ios on android hardware?
I would think at least partly it's due to lack of trying (doubt many Android developers would want to use iOS)... but the thing is, Android is designed to run on a lot of different hardware, whereas iOS runs on specific hardware, so they can do lots of specific checks if they really wanted to to make sure it's running on a real iPhone. This is just my educated guess of course.
The iPhone currently has a handful of carriers and only 4 hardware configurations. I'd imagine that a fair amount of information about the internals gets leaked as well.
I am unaware of the specifics of android development on that platform, but the biggest advantage their developer community has is less overlap and redundancy in their efforts (lack of fragmentation). Also note that Android is open source-IOS is not, so we only tend to see iPhone OS installed on Apple hardware.
I also have my suspicions that their grass isn't really all that green. Personally, I tend to favor fragmentation, as it fosters innovation(but YMMV!).
You didn't ask my opinion though
Cheers.
Android is open source so it can be adapted to almost all hardware. iOS is closed source so to adapt it you'd have to reverse engineer. And that is illegal. It's that simple. And been asked before. You should try searching, reading and thinking, it's wonderfull, doesn't hurt and you might learn something.
Sent from my HTC Desire using XDA App
The reason's pretty simple. In order to effectively port an OS to any particular device, you really need access to the source code.
On the one hand, with Android, Google literally gives the source code away. You know that AOSP term everyone throws around? It stands for Android Open Source Project, and is the website (source.android.com) where anyone can download the full Android source code and do basically whatever they want with it.
Then, there's Apple. They guard iOS' source code vigilantly and litigiously -- I mean, their over-protectiveness even extends to what apps they'll let run on (non-jailbroken) phones. So needless to say, they don't make it easy to take their OS apart and port it to other devices. Really, they make it as hard as possible.
Great answers guys thanx!
Yeah! Thanks for the answer Ik Desire! You Rock!
So it seems the NSA has released their source code for SE Android (previously they built SELinux as well). This is a more sandboxed and secured version of Android based on the work they did in Linux.
This is the basis for Government grade secure Android devices that they are intending to deploy.
The build instructions list using AOSP as the basis and building from there, as it's primarily kernel compiling. That being the case you could (theoretically) kang almost any rom by recompiling and repackaging. I have not released any rom's or anything like that, so this (for now) would be nothing more than a packaged release of vanilla AOSP + SE Android kernel. As I get my feet under me I might tinker with some customizing, but wanted to see if there was an interest, otherwise I will just knock it out for me and skip updating.
i'm interested to see what you can come up with. Develop is slow here so anything is greatly appreciated. I came from the hd2 and development there is still awesome.
Interested. Have any links for code information as to what they did to implement security?
Sent from my ADR6400L using Tapatalk
Sure thing:
Turd Furguson said:
Interested. Have any links for code information as to what they did to implement security?
Sent from my ADR6400L using Tapatalk
Click to expand...
Click to collapse
http://selinuxproject.org/page/SEAndroid
Looks like mostly they ported the SE linux stuff over.
I'm also interested in this, I'm planning on releasing a build of this spliced with CM7 on Rootzwiki, since nobody else had started it yet.
They've mostly only made the major pieces of SELinux working with the Android kernel, and have a few userspace modifications on top of that. It'd be alot more C/C++ work than Java I'm afraid if specific tweaks need to be built.
I'm planning on beginning work when I get back to the U in a few days. Will you have a repo we can pull from for building? I have distributed compiling capabilities and we're on a shared 300meg link, I can build/upload if you'd like from your base?
At a workshop I attended to present a research paper of my own back in October there was discussions of building hypervisors into Android to separate out normal app space & business(secure) app space such that even if you had an evesdropping bit of malware it couldn't listen in on the business phone app as it was separated from the normal app space where the malware would live. But tie that into a SELinux style android kernel would likely make it significantly more beneficial.
I wonder how hard it would be to put the two together? Or if SEAndroid would defend against such threats on its own w/ out needing to build in hypervisor level security as well? Guess it might be worth investigating but definitely interesting and excited to look at further. Thanks for posting!!
I'm interested!
I wonder if the CM team would consider merging this into their builds, that would put it in a league of its own...a powerful ROM with many enhancements and exceedingly secure...just awesome.
I'd be interested in this. I just stumbled upon the whole SEAndroid thing while looking for ways to secure Android from some (seemingly?) legitimate apps that nevertheless ask for massive permissions (i.e., Juicedefender). It's just extremely difficult these days to tell, as often these sensitive permissions may actually be needed by the app to conduct its business.
I've actually been waiting on taking the plunge to root my phone (yes, overcaution, I know)...a strong, secure ROM based on SEAndroid would make me do it!
I would be interested in this also.
any development for the tbolt here is welcome. id be interested to see how this plays out. thanks for the hard work im sure your putting into it
It looks like Marshmallow is following the usual pattern of Android "x.0" alpha release to the public, followed by "x.0.1" beta release with initial defect ('bug") corrections starting with Nexus beta testers (I.e. Nexus users in general).
Reading about the MM 6.0 problems on MXPE, I'm sitting out the 6.0 alpha testing on the sideline with LP 5.1.1. Most trouble-free phone I've had yet, and I don't yet need the only compelling feature I see with MM on the MXPE (T-Mobile Band 12 support).
Any noises yet about MM beyond 6.0.1? (I know I can look for this elsewhere too, but thinking maybe some of the XDA community may have inside info from the Android community.)
TIA...
The marshmallow update give me some new features and better battery life (though I do own the X Style, not pure). Unless you are dead set on being intentionally obtuse, then this isn't considered an alpha update.
Also the 6.0.1 update is quite minor, the largest change being some ART performance improvements, the rest is adding bands to the Nexus line and some emoji's: http://www.androidheadlines.com/2015/12/google-posts-android-6-0-1-changelog.html
I know the label "alpha" is not not the official label for something like 6.0. But with so many substantial defects, and multiple forthcoming revisions to correct those defects a certainty, that's really what it is IMO. Maybe "public release alpha" would be a better description, since pre-release revisions go through even more defect-ridden levels including pre-release alpha, prior to public release.
Similar situation with previous Android versions, and in fact most software foisted on the public these days (I'm looking at you, Microsoft and Apple). Look at Lollipop and the multiple public release revisions it took to iron out most of the substantial defects, finally, with 5.1.1.
6.0.1 is not just "...some ART performance improvements, the rest is adding bands to the Nexus line and some emoji's...", it also includes defect corrections. (Bluetooth, anyone?) And if the changelog doesn't list a significant number of defect corrections, that doesn't necessarily mean it is already polished at 6.0.1. The fragmented Android ecosystem and separation between Google, phone manufacturers, carriers, and users guarantees a plethora of various non-trivial defects in the ecosystem, many of which Google will address only slowly or even never for most phones.
For example, the memory leak defect in LP was not fixed until 5.1.1. How may revisions and months did that take? How many phones still run pre-5.5.1 with this defect?
One reason I bought the MXPE was the idea that it would be one of the first to get the updates. That turned out to be overly optimistic. It looks like Nexus is the only one still close enough to the source to get timely updates, and it also looks like Google is not pursuing Android defect corrections with any kind of urgency at all nowadays, maybe because the hardware ecosystem is becoming way too diverse to adequately support any more (or maybe because the profits roll in no matter what). Motorola phones, with the Moto alterations to Android, outsider status with carriers, and now hollowed-out Motorola support, appear to be no closer to adequate Android support from Google than any other non-Nexus phone.
"Obtuse"? A "bug" is a euphemism for a defect. Let's stop being obtuse, and call it what it is.
Any other info also appreciated.
You're being obtuse by insisting that we're all public alpha testers.
You obviously have no idea about software development, nor about Android Open Source development. Not your fault, but running your mouth is.
You bemoan the memory leak fix took several revisions to fix. So, you think that Google dedicated the whole team to fixing that one bug? What then? No other bugfixes or features are introduced in the meantime? The likely case is (and this is from experience) that bug took some revisions to fix, in the meantime, Google were also pushing ahead with other fixes. Regardless to what the uneducated (about SW development), throwing 15 developers onto one problem doesn't solve it any quicker. 5.0.1 came, adn 5.0.2 came, then 5.1 came in the meantime. While that memory leak was being worked on, more releases come fixing other things. Be grateful they didn't listen to you and leave it at 5.0 for several months while they fixed one issue.
Whatever bluetooth fixes that you think are in 6.0.1 are pure fantasy, because none exist in AOSP 6.0.1: http://aosp.changelog.to/android-6.0.0_r5-to-android-6.0.1_r1.html <-- That's the FULL changelog of commits between 6.0.0_r5 and 6.0.1_r1.
It is not Google's job to fix a problem in anything other than their own devices. At all. Google's job is to make AOSP run smoothly on Nexus devices and release the source. Samsung, HTC, LG, Motorola et al all take the source code, just like CM, AICP, Slim and the rest do, and make modifications for their devices, using the sources given to them by their hardware partners and themselves. So if BT works in Nexus devices, but not others, then it's not Google's problem (usually). An AOSP issue will persist several devices, including Nexii devices.
Google also have taken on the quite large undertaking of monthly security updates for their devices, which I can tell you will be taking up some of the development teams time (it's what, 3-4 months into that project?).
No software ever released on this planet comes without bugs and issues. This is software development. You can check the status of AOSP development here: https://android-review.googlesource.com/#/q/status:open and feel free to download, code and submit your own features.
MattBooth said:
You're being obtuse by insisting that we're all public alpha testers.
You obviously have no idea about software development, nor about Android Open Source development. Not your fault, but running your mouth is.
You bemoan the memory leak fix took several revisions to fix. So, you think that Google dedicated the whole team to fixing that one bug? What then? No other bugfixes or features are introduced in the meantime? The likely case is (and this is from experience) that bug took some revisions to fix, in the meantime, Google were also pushing ahead with other fixes. Regardless to what the uneducated (about SW development), throwing 15 developers onto one problem doesn't solve it any quicker. 5.0.1 came, adn 5.0.2 came, then 5.1 came in the meantime. While that memory leak was being worked on, more releases come fixing other things. Be grateful they didn't listen to you and leave it at 5.0 for several months while they fixed one issue.
Whatever bluetooth fixes that you think are in 6.0.1 are pure fantasy, because none exist in AOSP 6.0.1: http://aosp.changelog.to/android-6.0.0_r5-to-android-6.0.1_r1.html <-- That's the FULL changelog of commits between 6.0.0_r5 and 6.0.1_r1.
It is not Google's job to fix a problem in anything other than their own devices. At all. Google's job is to make AOSP run smoothly on Nexus devices and release the source. Samsung, HTC, LG, Motorola et al all take the source code, just like CM, AICP, Slim and the rest do, and make modifications for their devices, using the sources given to them by their hardware partners and themselves. So if BT works in Nexus devices, but not others, then it's not Google's problem (usually). An AOSP issue will persist several devices, including Nexii devices.
Google also have taken on the quite large undertaking of monthly security updates for their devices, which I can tell you will be taking up some of the development teams time (it's what, 3-4 months into that project?).
No software ever released on this planet comes without bugs and issues. This is software development. You can check the status of AOSP development here: https://android-review.googlesource.com/#/q/status:open and feel free to download, code and submit your own features.
Click to expand...
Click to collapse
t
No new or useful information there. Thanks anyway, despite the ad hominem. I guess that comes with the territory (forums).
Yep, the Google-Android-(independent hardware makers) ecosystem is seriously flawed. Too much disconnect between the OS owner (Google), the hardware makers, the carriers, and the customer. And the first three in the chain (not including the customer) have different incentives/disincentives, and there are a bazillion hardware variations, of course it is broken. We know all this.
Reminds me of the original PC/Windows mess. Except worse because the carriers interpose an additional dysfunctional layer hindering OS updates/support. (Before anyone says "just DIY with one of the many available ROMs, I started this "Q" thread about stock MM, not third party ROMs.)
Still hoping for any useful information on anything happening to fix the MM defects, to get an idea when it might be past public beta and worth installing to MXPE.
TIA...
Tinkerer_ said:
t
No new or useful information there. Thanks anyway, despite the ad hominem. I guess that comes with the territory (forums).
Yep, the Google-Android-(independent hardware makers) ecosystem is seriously flawed. Too much disconnect between the OS owner (Google), the hardware makers, the carriers, and the customer. And the first three in the chain (not including the customer) have different incentives/disincentives, and there are a bazillion hardware variations, of course it is broken. We know all this.
Reminds me of the original PC/Windows mess. Except worse because the carriers interpose an additional dysfunctional layer hindering OS updates/support. (Before anyone says "just DIY with one of the many available ROMs, I started this "Q" thread about stock MM, not third party ROMs.)
Still hoping for any useful information on anything happening to fix the MM defects, to get an idea when it might be past public beta and worth installing to MXPE.
TIA...
Click to expand...
Click to collapse
What ad hominem? Your uneducated state affects your ability to understand the nature of Android and software development. It's a perfectly legitimate response to your position. You lack the ability to understand and therefore your argument is flawed. I'm not attacking you, I actually tried to give you some insight into how it works, but you're not really interested and would rather insist on this "public beta" bull.
As far as fixing any "defects" you suppose, you haven't actually listed any so no-one is going to be able to help you with temporary work around without a list of what you feel is broken. I also showed you the changelog, so you can do your own homework to see if your supposed defects are fixed in 6.0.1.
The various hardware configurations doesn't even matter because Android is built to deal with it. So long as the hardware vendors of chips and modules support them properly and give out functioning binaries to OEM's, or proper source code, it's irrelevant. The exact opposite of what you said is true, Google has a very close relationship with it's partners (anyone signed up to their Google programs, to preinstall Google apps). The problem is carriers, who really shouldn't have a say in software on the phones, but that seems to be a chiefly North American problem.
Google doesn't need to have any connection to Android users as customers. Google does not sell Android, therefore you are not Google's customer unless you use a Nexus phone. Google sell the Google Experience, with the Nexus. You are Motorola's customer, and you are using Motorola's branched version of Android. Google doesn't owe Motorola any fixes or patches for their device. Motorola must maintain their own device tree and maintain their own relationships with their partners.
EDIT:
Also, Motorola's problem is resources. They have four version of the Moto X 2015 to deal with, three versions of the Moto X 2014, the new X Force, then the various versions of the G and E to deal with, along with two smart watches, and so forth. Their line up is increasing whist I imagine their development team is not. There was outrage (rightly so) when news broke that the Moto G 2015 wasn't getting the MM update, despite being a couple of months old, and Motorola listened and OTA's are rolling out.
I am asking if anyone can offer any info on anything being done to move toward MM revision with the many significant defects of 6.0 corrected. Read the forums, there are way too many defects with 6.0, it is patently a de facto public alpha, and we are tracking the usual pattern where it takes 3 to 5 revisions before an OS major rev is ironed out enough that upgrading will not cause more problems than it fixes.
There are always excuses made for why there are so many defects in software. There is a euphemism for "defect" everybody uses, "bug". Everyone has been making excuses for so long about shoddy workmanship and inadequate testing and correction of software, with the "bug" euphemism to minimize the reality that these are defects, that we are all just to suppose to accept systems ridden with faults without complaint. It's unacceptable. It can be done better. Part of why it doesn't get better is because everybody says "that's just the way it is, deal with it". With mountains of byzantine excuses and even ad hominem attacks (as here).
This thread was not started to start a tit for tat ad hominem back and forth, nor to post long essays detailing excuses for the pathetic status quo of the fragmented Android ecosystem with respect to defect causes and distributions. It was started looking for any info about work being done to fix the stock MM defects. Still seeking info.
TIA.
You should probably check the definition of ad hominem. There was no attack on you as a person, just pointing out that your uneducated state with regards to knowledge about software development affects your ability to call judgement on this.
But you haven't listened to a single word I've said and still maintain a shoddy position, so I would suggest to anyone else who reads this to simply ignore you as a troll.
Tinkerer_ said:
It looks like Marshmallow is following the usual pattern of Android "x.0" alpha release to the public, followed by "x.0.1" beta release with initial defect ('bug") corrections starting with Nexus beta testers (I.e. Nexus users in general).
Reading about the MM 6.0 problems on MXPE, I'm sitting out the 6.0 alpha testing on the sideline with LP 5.1.1. Most trouble-free phone I've had yet, and I don't yet need the only compelling feature I see with MM on the MXPE (T-Mobile Band 12 support).
Any noises yet about MM beyond 6.0.1? (I know I can look for this elsewhere too, but thinking maybe some of the XDA community may have inside info from the Android community.)
TIA...
Click to expand...
Click to collapse
I think we'll close this debate. There are no real "Android" insiders on XDA, so asking for update info which is privy to Google is perhaps somewhat futile.
On a related note, XDA have a few dedicated "Android Fora", such as this complete Category where non-device specific discussion and indeed conjecture takes place. Perhaps you could take a look there and see what transpires?
Thanks
As seen here
https://www.reddit.com/r/LineageOS/...ect_trebel_devices/?utm_source=reddit-android
LineageOS team state that project treble is in its baby shoes and completely dependant on google to optimize it even more since as of now gsi rom requires certain adjustments for each device, so will project treble successed?
any1 has an insight please share.
I think it needs more adjustment. The kernel should be universal and updateable along with the OS, it's pretty universal as it is at the moment. Drivers should also be standard and updateable, at least for standard items. There should be a driver model where possible to support other devices, and any phone specific changes could be done through manufacturer supplied drivers. There's really no reason why it can't be done, it would be along the lines of how Windows works. Of course, it can be tailored to suit phones.
System updates should realistically come from Google, it would mean all phones and devices would be up to date with the latest security updates. The phone can also check with the manufacturer for specific updates. If Google keeps them apprised of any changes they can update their specific updates in time. This model would mean individual service testing for a new OS update etc wouldn't be a problem since it should at least be compliant with the base model.
Don't forget Google tracks down security leaks in other OS like Windows, which isn't even a direct competitor, and releases the security leak information if it isn't patched within 30? days. How many Android devices are updated with security patches within 30 days by the manufacturer? It's very much a double standard. Google really needs to think of an even more universal model like I just depicted for Android 10 Quinoa Slice (or whatever they call it).
Will Treble succeed? It's a step in the right direction, but needs more work. Not only should something like I just described be done, it should be made mandatory for all new devices. It doesn't mean custom versions are out, but custom versions would have to have OTA updates and be updated quickly along with the standard OS.
To say whether it succeeded or not, I think you'd first need to define what's its goal.
I still don't even know the answer as of today.
Some people say that the goal is to have a system image controlled and updated by Google.
But I don't see this happening any time soon. Google would need to test their GSIs on many devices, and they didn't even test P GSI over O-MR1 Pixels!
It seems to me that their goal was simply to make updates easier to OEMs. Considering Essential PH-1 getting Pie day-one, this might seem a success.
But we'll need to compare Oreo adoption rate to Pie's to confirm.
Oooh someone made a thread so i can moan cheers
The main problem with treble for me is that it's splintered between a plethora of devices, so one dev will release a treble rom and a multitude of device owners will flash it, each with their own subjective problems and issues, requests and wants.
And there lies the problem, it's difficult even when it's a dedicated rom thread for a particular device to get help at times.
So when you have a bunch of users talking about completely different devices you haven't got a hope in hell.
I think there should be branches to each thread for each specific device, that way help threads can be more linear rather than the chaos that it is at the moment.
Least that's my thoughts
My only rom i've flashed is RR and besides a few missing features, Fingerprint, Stereo and NFC i think it's brilliant.
Hi,
i want to dive into the world of android head units.
However, when i search for android head units i do see Android 10 devices but not a single Android 11 device.
Are there any on the market or going to be released soon. Or any updates for existing android 10 Units?
Best regards
No Android 11 yet
What are the odds, that existing android devices gets an update? Maybe by the xda community?
I know its glass balling, but i dont know the state of the android auto comunity.
And if there are good chances, what device to pick up yet?
XDA will not provide updates.
Note that all these units contain a lot of closed source software, including the MCU firmware, for the specific hardware. It is not a phone or a tablet. It needs to communicate with all kind of hardware.
To be able to compile a new Android version, XDA devs would need the complete source. You can completely forget that.
The hardware builder (not as such the reseller) needs to provide that upgrade.
Well and i guss the chances that any china hardware builder or "regular" builder will provide updates is very limited.
MasterOran said:
Well and i guss the chances that any china hardware builder or "regular" builder will provide updates is very limited.
Click to expand...
Click to collapse
They are hardware builders, and they are in the business to make money like everyone else. For that reason, continuously updating older hardware is (understandably) not in their best interest.
When 11 comes out... and it will, it will be on new machines. If you want it on your older machine then you will have to wait even longer for a hacked version and install method geared for your exact machine.
That's just the way it is!
I'm not sure though what you hope to accomplish with Android 11 that you couldn't accomplish with 9 or 10. There is really not a whole lot of difference in the versions themselves... a couple of minor tweaks here and there as well as a few cosmetic changes. It's mostly the hardware which changes and of course the associated software must also change to accommodate those hardware changes. But when I think about the change from 9 to 10, there was really nothing there to stand out.
Bob_Sanders said:
They are hardware builders, and they are in the business to make money like everyone else. For that reason, continuously updating older hardware is (understandably) not in their best interest.
When 11 comes out... and it will, it will be on new machines. If you want it on your older machine then you will have to wait even longer for a hacked version and install method geared for your exact machine.
That's just the way it is!
I'm not sure though what you hope to accomplish with Android 11 that you couldn't accomplish with 9 or 10. There is really not a whole lot of difference in the versions themselves... a couple of minor tweaks here and there as well as a few cosmetic changes. It's mostly the hardware which changes and of course the associated software must also change to accommodate those hardware changes. But when I think about the change from 9 to 10, there was really nothing there to stand out.
Click to expand...
Click to collapse
I though they gonna implement wireless mode deeper into android 11. Thats why i asked for android 11 devices.
MasterOran said:
I though they gonna implement wireless mode deeper into android 11. Thats why i asked for android 11 devices.
Click to expand...
Click to collapse
These are not Android Auto... These units are cheap hacked Chinese Android and in no way Android Auto.
If you want Android Auto, buy a genuine certified Android Auto unit.
MasterOran said:
I though they gonna implement wireless mode deeper into android 11. Thats why i asked for android 11 devices.
Click to expand...
Click to collapse
Well first, Android 9, 10, 11.... etc is just your basic run-of-the-mill Google Android operating system and really has nothing to do with what the unit will support or not. That's up to the head unit manufacturer with what hardware they supply on the unit.... and the CUSTOM software they write/modify to work with that hardware
Second, these devices do not now, or will ever officially support AA/CarPlay, so it will forever be a crap shoot on whether you can get it to work or not. Put it this way... if RELIABLE aa/carplay is important to you then you probably should NOT be investing in Chinese android head units!
Okay so i got a wrong perception of the android auto system.
I thought, that the majority of features are built into the google android system. Like wireless aa mode and so on, therefore new android version --> new/improved features.
While the hardware supplier could use standardized "hardware" interfaces to connect their hardware things. Very much like phone manufacturers connect cams, sensors, etc. The same way i could attach USB devices to an OTG-USB Phone or NFC devices and so on.