3 ms·
>Also, the problem isn't unknown hardware (as you would suggest by saying they should use "known hardware"). No, the failure point here is, essentially, unknow
by cube13 14y ago
>Also, the problem isn't unknown hardware (as you would suggest by saying they should use "known hardware").
No, the failure point here is, essentially, unknown hardware from Google's perspective. Android is not coded to work specifically with Samsung's configurations or hardware, so Samsung needs to provide drivers. As for "more rigorous" requirements, I don't think it's too hard to have the requirement that all drivers follow standard *nix security practices. That would have stopped this completely.
So the solution is to either not allow custom OEM builds(which, as I noted, isn't possible for Android).
- mdwrigh2 14y ago> No, the failure point here is, essentially, unknown hardware from Google's perspective. Android is not coded to work specifically with Samsung's configurations or hardware, so Samsung needs to provide drivers. As for "more rigorous" requirements, I don't think it's too hard to have the requirement that all drivers follow standard * nix security practices. That would have stopped this completely. This is obviously a boneheaded mistake, but how do you verify that all drivers follow "* nix security practices" (and I'm still not entirely clear exactly what those are nor how they differ from generic security practices) short of an in-depth security audit for each new piece of hardware. It isn't enough to have requirements, you have to have to be able to validate them. >So the solution is to either not allow custom OEM builds(which, as I noted, isn't possible for Android). Is there a second part to this "either"?