> a dedicated work profile that isolates and protects work data
Oh wow, can this be used to just create a separate profile for every app? That way I can run Uber or Line without giving them every permission to everything? This is the biggest reason I do not install apps. Every "famous" app requests so many permissions it's just stupid.
And not to mention the weirdness of some of them, like "WiFi Device Information". What's that mean? Access to my WiFi AP names? No thanks. Or just local multicast? Who knows.
CyanogenMod's Privacy Guard is useful for dealing with this situation. There is a setting to enable it by default on newly installed apps. No matter what permissions the app says it requires, you are prompted when it actually requests them and can deny them at will or permanently.
Why do I need a custom ROM for privacy? This is so wrong. Great that you can partially fix this but what about the millions of other users who also want to control their privacy without reflashing a complete ROM.
CyanogenMod comes preinstalled on OnePlus One, so for me it is no longer a "custom ROM". Even though it is not rooted by default, Privacy Guard has been working for me out of the box from day one.
Doesn't crash, but sometimes apps seem to be created under the assumption their permission request isn't creating a popup, so there are sometimes like 10 in a row, so the user will often give up and just either blanket deny or accept
EDIT:an "allow for 10 min" option would resolve this
The lack of a "for 10 minutes"-type option is, IMO, the biggest failing of Privacy Guard. XPrivacy is better in that regard, but was harder to use overall when I last tried it.
XPrivacy does have the benefit of making it easy to provide realistic-looking fake data, which I believe the CyanogenMod team is against.
In my experience, the apps I've used don't crash. The biggest problem I've seen is me getting frustrated with an app for not working as advertised. Then I remember that I've enabled privacy guard and the app must not be getting some info it needs from the OS.
Code that assumes it is going to get data instead of allowing for an empty response (in a circumstance where this is technically possible in reality but so rare the developer didn't thing to allow/test for it) could cause misfunction.
While I'm not exactly certain on how Privacy Guard works (I have yet to examine that code base), if a phone returns [] for a list of contacts and the application crashes...
If you have a rooted device, try XPrivacy. That gives you a lot more options and you can even set what data you want the app to see. Want those apps that are asking for your location to think that you are on the North Pole? No problem.
Just for the sake of clarity, do you mean that there are more apps that are sandboxed on iOS or that all apps have a higher level of sandboxing on iOS?
More "sandboxed" in the sense that iOS apps start in a small sandbox that gets progressively and opportunistically larger. Instead of demanding all permissions upon installation, they demand them contemporaneously with attempted access to certain resources. The idea is that user consent is more informed.
In contrast, Android apps demand all of their permissions up front.
More importantly, if you ask me: iOS allows you to install an app, and deny it permission to something. Eg. I can deny the Facebook app access to my contact list, and the app still works.
With Android, you grant an app access to everything it asks for, or you aren't allowed to install it. This seems obviously inferior to me.
I consider that a weakness of iOS as a platform. There are some pretty cool and useful things you can do with an Android app that you just can't do on iOS, period.
Android's permission-granting model does leave much to be desired, though.
This is the other edge of the privacy sword. Look at OSX applications distributed via the Mac App Store vs traditional methods. The Mac App Store is very limiting but far more secure.
Intercepting calls before they go out through the main dialer, and instead using some form of VoIP.
Intercepting an incoming SMS that's used for phone number verification, rather than requiring that the user switch to their SMS app and manually enter a code.
For that matter, replacing the SMS app with something better.
Reasonable app backgrounding support for any purpose you can think of, not just for those that Apple has graciously allowed you to do.
Hell, you couldn't even have custom keyboards on iOS until recently.
Apps can also have access to stuff that iOS never allows: e.g. I have a 3rd-party app that backs up my SMS database to Google Drive every night. It can also do backups to Dropbox and a couple other services. With iOS your one and only cloud backup solution for "system related things" is iCloud, and you can't change that.
None of these things require rooting the device. Yes, all of these things can be abused. But I prefer permissiveness that requires a little vigilance on my part over living in a restricted environment.
Another: the inSSIDer Android app isn't available on iOS, because it requires permissions to the wifi hardware that iOS doesn't give permission to. This is one of the apps I really miss after moving from Android to iOS.
Running in the background is on I stumbled with porting an app from Android to iOS. what an an iOS app can do while it's not the current app is tremendously limited. This is for battery reasons, and I get it, but it would be nice if the choice was up to the user; instead Apple just decided the practice was unacceptable.
The second option, that all apps have a higher level of sandboxing. Until iOS 8 apps couldn't do anything to modify the OS besides adding push notifications and maybe a page in the settings.
> Oh wow, can this be used to just create a separate profile for every app? That way I can run Uber or Line without giving them every permission to everything? This is the biggest reason I do not install apps. Every "famous" app requests so many permissions it's just stupid.
iOS does not require the user to accept all permissions that an app wishes to use, before installing that app. On iOS, you install an app without giving it permission to much, initially, and then the app, when you start it, starts asking for permissions that it needs, as it needs them. You can deny any permission request, and the app still works.
Eg. you can install the Facebook app, and deny it access to read your contact list.
In iOS, there are about 10 permissions (location, contacts, calendars, reminders, gallery, bluetooth, microphone, motion, twitter and facebook accounts).
In Android, about 150.
There is no mapping 1:1. Some things iOS does not allow at all (wifi information, sd card access). Some things iOS allows by default, with no way to deny it (internet access).
The iOS approach would not scale, the user would be burried under confirmation dialogs. And that's just the initial confirmation, there has to be UI, when he changes his mind later.
Those, who claim that iOS approach is superior are showing their ignorance, that they newer thought about the way, how the user would set matrix of this amount of permissions with many apps, without getting lost (hint: many are getting lost just in the current system. Imagine, that they would be able to toggle anything. And imagine, what the developers would say about that).
I understand the discussion of app permissions is not a new one, but today I decided I wanted to try and buy a product through Amazon outside of the browser... Amazon specifically instructs you to navigate to your settings and allow installation of 3rd part apps. Then it directs you to download their .apk - To this point I was almost to the point of excitement that a MAJOR company is showing the public that this is even possible.
Then I opened the .apk. It asked me for what has to be every permission available on Android. Why would Amazon need access to me Contacts? It even asked specifically for permission to my microphone! What?
Unless i am mistaken, Amazon can't give premissions to another app install. The user has to leave the "unknown source" option checked as each APK installed goes through the same rigamarole.
Play gets around this by being bundled as a system app initially. And if you have a rooted device you can potentially promote the amazon store to the same status, and so forgo the "unknown sources" switch.
Please correct me if I am wrong but I thought this was for sharing your phone with someone else or sharing your phone between two or more Google accounts...
I think Facebook Messenger, Line, and the like will still have access to all permissions even if you switch to a different user and install the apps there...
That being said, guest mode is really nice on my nexus 5 so my curious friends on iPhone can log in to their google account on my phone as a guest and test drive android.
I think the idea is, you create a dedicated "sandbox" account, install apps in it that you don't trust that want access to calendar, contacts, text messages, etc., and then don't put any real data of those kinds in the account. So, they still have permission to see those things, but they don't see anything when they look.
Note, I have not looked deeply, so maybe it doesn't work like I said. I would not expect multitasking to be very seamless with this method. Also, I know there are some permissions that have "cross-user" abilities, so maybe there is still a way to accidentally allow an app to access your real data.
blackberry allows blackberry users to choose what permissions they won't allow access of in their apps. This doesn't work with the android apps but works rather well with blackberry apps.
For example 2048 game has a lot of permission but being a game I don't allow a single one and it still works flawlessly. I would love to see something like this in android as well. But for now users are at the mercy of app developers.
You can use Xprivacy with Xposed to feed an app fake or empty data on a permission by permission basis. This works better than blocking permissions because sometimes apps don't fail gracefully when a permission is denied.
Yeah, but I have a Huawei Mate 2, which, last I looked, had some really obscure rooting instructions. Most steps consisted "download this random exe and give it admin permissions". Plus you have to email Huawei and ask nicely for the bootloader unlock code.
And, rooting doesn't help the majority of users. Whereas protection from spying would. But Google, perhaps accidentally, seems intent on making permissions less visible and has no problem with devs requesting every permission. And since so many major apps do this, users have no effective recourse.
I suggest that anyone considering sharing a personal device with work activity (other than basic phone calls and messaging, e.g. "I'll be in late") think twice.
Comes a security concern or conflict, someone's probably going to want access to the whole thing.
If you want me to do "your work" on a phone -- particularly as an employee as opposed to as an independent contractor utilizing their own resources as defined in the contract -- then give me a phone. A hassle, but on the other hand some protection, in exchange for a few additional ounces (phone weight) of prevention, as it were.
Just like I don't want to use my own computer to host their work/data. Nope. When the relationship ends, I turn in their equipment and there is no question as to whether all relevant data has been expunged. They have the entire device.
I'm a stickler about this. Beyond answering the odd phone call or message, I have a hard time seeing it as anything but the company unfairly attempting to externalize costs onto their employees.
Just like you give me a work computer to do work related tasks on, the same should go for mobile devices.
My employer used to be rather liberal but recently started clamping down on security. They wanted us communicating in the company chat on our phones so we installed the chat app. But now with the security clamp down they want to set security requirements on anything that accesses potentially sensitive information, meaning they want to dictate the security policy used on our personal devices. I told them to go stuff it, if its a choice between no work stuff on my phone and letting them set the policy on my devices, I'll go without access to work stuff. I'm not going to play that game with you, yes I'm willing to be That Guy that takes a stand on this.
The real irony is that my security policy at home is more strict than the one at work, but they conflict somewhat and I'm not willing to reduce my home security to accommodate them.
> Just like you give me a work computer to do work related tasks on, the same should go for mobile devices.
I'm issued a mobile phone by my employer. Today I don't have any option to "carve out" a niche for my personal activity on my phone. AFAIK they can know anything and everything. Google Play for Work sounds like it would help out here.
I was issued a work phone too. I decided it was much more worth it to carry around two phones, with my work phone in my bag for the .01% of the time they actually needed to get in touch with me. Work only needs to know my work number, they shouldn't, nor needn't, care what I do on the 80+% of the time I'm not on their clock.
This is right, theoretically, but I'd love to see the stats on how many people carry two phones everywhere. It's either BYOD or someone using COPE for personal stuff. Not sure which is worse.
Where I work, they told us upfront "you can have your work email on your personal phone, but if we need to do an investigation for any reason, we're taking your personal phone". And they happily handed out work phones.
Of course, I've worked in security in other companies where employees had their work email and data on their personal devices, and in the event of a security incident we were not allowed to touch their personal devices even though there was work data on it. So it goes both ways.
Would secure-wiping the phone if involved in a legal discovery process be considered destruction of evidence?
Does your advice apply when you're only using, say Exchange, as your only entry point (e.g. on iOS devices?) - in this case, all discovery can be done server-side.
I find it hard pressed to think this issue hasn't been covered more rigorously.
Part of my argument is that, when you as an individual are on one end of an argument about this with a substantial business/corporation and/or the government, you are going to have a rather difficult time, regardless of what is "right" and "lawful".
Better to be able to hand the device over and say, "Have at it."
Also, if there is some breach of security and a question about whether you facilitated it, through activity or through negligence, better to be able to say/demonstrate to the other party: "It's the organization's device, and the organization's / the organization's IT department's responsibility to maintain it."
However if prior to receiving notice of the hold you'd wiped it as part of a documented data retention policy, odds are far smaller of falling afoul of legal process.
Sudden change of policy in conjunction with other shady events, harder time.
Awkward naming aside, it seems like this is very similar to what Apple did in iOS2.0 with iOS Enterprise Developer program.
"Google Play for Work allows businesses to securely deploy and manage apps across all users running Android for Work, simplifying the process of distributing apps to employees and ensuring that IT approves every deployed app"
Leaving aside exactly how it's done, the end goal is the same: If I am Example Inc's CTO, I can now have my staff develop Example Inc Android apps that are neither sold on Play store nor side-loaded.
Apple requires running your own App Store server, I'm fairly certain Google will probably make it more cloud centric.
I think you are confusing use cases, the iOS Enterprise Developer program is something totally different. It serves companies who want to either test own apps within the organization or use own apps just for internal use (like intranet apps). Meanwhile the program got rather abused for doing test flights and beta tests.
What Google does is different: the company IT can decide which apps are allowed and they can automate installation, e.g. company xy wants to install Salesforce, Trello, and 5 other apps on company devices in addition to the OS apps.
Google Apps has supported private Play channels for ages, allowing you to use the same Play app to install business apps restricted to only users in your Google Apps account. This seems to be more about being able to automatically push those apps to your user's phone.
Could be worse. I still remember when Microsoft maintained both "Windows Messenger" and "MSN Messenger" as separate apps with separate update schedules and version numbers even though it was the same product. That was confusing.
As best i recall it started with Windows Messenger, aimed at intranet use (and with a client bundled with Windows, natch). Then MS used the same protocol to offer a AIM competitor. In the end though what they killed seemed to be IRC...
A bus station is a where a bus stops. A train station is where a train stops. So what is the purpose of a workstation? And more importantly, what is the purpose of a PlayStation? ;).
The name is silly, but it makes sense. Google Play is effectively a package manager. "Google Play for Work" is an enterprise-controlled package manager.
Oh yes, it makes perfect sense if you ignore the fact that "Google Play is a package manager" doesn't make any sense. Google Play should be a thing on which you play, not manage packages.
It could have been called "Google Package Manager for Work."
> "Google Play is a package manager" doesn't make any sense.
It makes totally sense. Google Play is a package manager like apt-get, npm, etc. and Play is a nice name which covers many uses case since it's a playful synonym for "start" or "to start something": "start a game", "start a program", "start an app" or "start work"
The term 'package manager' would be to long and is not learned among the mainstream but again it's exactly this, check Wikipedia:
"A package manager or package management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing software packages for a computer's operating system in a consistent manner. It typically maintains a database of software dependencies and version information to prevent software mismatches and missing prerequisites."
On a basic level its a "container" that uses selinux to create a separate security space in which "work" apps and data live, so they they don't mingle with your personal apps. The Android for Work administrator has complete control over that part of the phone, but can't touch any personal apps or data. There are also updated email/calendar/contacts apps. This made mainly to address BYOD scenarios.
I don't mean to beat on Blackberry but I too thought of Blackberry when reading this. I had a different approach though. This was the sort of approach that Blackberry optimized to lock out any competition from the enterprise. Apple/iPhone was just soooo good that eventually IT departments had to capitulate and work with BYO devices. Things like the US government were the last to cave so you Obama had a blackberry for a long time. So Google _seems_ to be catering to that crowd with this but that's a ship that's kind of sailed. There might be a few stubborn outposts but if half my company (including the entire C suite) has an iOS device are we really going to get value out of implementing this Google stuff?
This would be a lot more compelling if, when I got a Google voice voicemail and saw that in my Gmail app on my "Google Experience" Moto-G and clicked on the "listen to it" link it didn't just vanish leaving me with an open browser and no message.
I like my phone, it works for me, but the sheer disconnectedness of it all is really jarring. Things show up in random places, or not at all, (especially media), and there is no "data connectivity" from anywhere to anywhere else, the same text message appears in my GVoice app, my Gmail app, and as a text message in Messaging.
How do you even begin to make a coherent business tool out of that?
> same text message appears in my GVoice app, my Gmail app, and as a text message in Messaging.
The "official" way to deal with this is to go to the Google Voice site and turn of emailing yourself every text. Then install the Hangouts app and enable SMS through Hangouts. Then disable notifications in the Google Voice and Messaging apps.
Result: On phone Hangouts handles texts + voicemail + Google chat, and on desktop GMail (or the Hangouts extension for Chrome) handles them.
At least, that's my understanding of what Google's intended best practice is.
You don't need Google Voice at all anymore (that I am aware of) and Messaging just goes to sleep when you make Hangouts your SMS app.
GV integration is not the most seamless perfect experience ever (for example, incoming IP calls go straight to voicemail when I'm on corporate WiFi) but I'm fairly pleased with it.
Google really did drop the ball on messaging.
Hangouts was supposed to progressively regroup all these messaging capabilities in one service, but the SMS integration alone has been so bad that Google rolled out a separate SMS app after deleting it in the first place (the new version is an improved Material revamp, but it still serves the same purpose).
There is probably a very interesting insider story behind this cock-up.
In the mean-time, I hope that Google will learn from these attempts and improve Hangouts in meaningful ways. Sundar Pinchai has already alluded to the fact that Hangouts and Photos are going to be treated as entirely different teams/services than Google+, which is probably a good start.
Looks like they are going after Microsoft on a different front. Especially with the notes and outlook integration. Can they provide enough of a productivity boost to get people to dump the windows ecosystem? Will IT managers be comfortable with cloud managed systems?
Right, on a device with a closed source baseband. On a platform where the vendor has shown to install new apps without getting active consent from the user (Google Play Games, Hangouts, Google Now, Play Kiosk) to name a few.
I hope this will appeal to our management, at the moment we have to use this horrible, horrible Vodafone-at-work app on Android (https://play.google.com/store/apps/details?id=com.mobileiron...). I crashes, it ask for a password constantly, separate from your system password, it cannot show appointment in your normal agenda or the lock screen, it drains battery.
They switched to it because some apps for android "lied" to our exchange server and said that mail was encrypted locally while it was not, passwords would not even be necessary (I think that was solved in Android >4). The Vodafone app caused many people to just stop syncing work related accounts: Not worth the trouble.
Looks like anoher thing would follow pc world. Initially companies allow personal laptop to be connected to work as long as you had correct version of patches and so on but with increased focus on security in most large organizations they have moved back company provided laptop. Same will happen here? Another issue a lot of good andriod's come with single sim hence you will anyway need a second (may be dumb phone) phone. Or does people use office phone for personal use , i mean where websites ask for your phone number? Because in India when leave a company (which is on an average one in 3 years) the company take the SIM back with number. And many folks have 2 sims for personal use itself so will obivously need office to provide the phone.
For work on Android I really need native split-screen support. Samsung-specific "multi window" is not a solution.
A proper window tiler would be even better.
Also the interface needs slim UI controls and slim window decorations, basically a "pro mode" theme-switcher for larger screens and mouse/keyboard users.
Because centralized control by IT has worked so well for corporate security over the past few decades...
I don't understand why organizations still want implement an IT paradigm which has done nothing but fail at its primary goal but has held back innovation and made workers miserable.
All the negativity aside can someone post what this brings to the market. What can android for work do essentially that other androids can't ? What does this bring extra to average android users?
Why would average android users care? It's not for them. But I work for a large company which allows me to use my own device for work purposes,but I have to install a 3rd party sandboxing app, which encrypts everything inside it and allows our IT department to remotely wipe it if needed. If Android supported this natively, we wouldn't have to spend big $$$ on a 3rd party solution.
do you really want Google to be reading all the mail on your non-gmail accounts? If you want that, you can set up forwarding on your non-gmail account to send all your mail to a gmail account, and you'll get cards.
Personally, i'd rather have the option for google to not read some of my mail.
I tried to find any info about license or repos and couldn't find anything. Unlike Samsung's Knox, which is FOSS, how can this be even remotely secure if it is closed source?
Seems that Google is full on the "Extinguish" phase with Android.
edit: amazing that I'm being downvoted for stating facts yet nobody replies to me.
It's a platform feature, so it's open source, but there's always a delay between the announcement and the time the code hits the public repositories. It'll be there before too much longer.
how can this be even remotely secure if it is closed source?
It does not work that way. "Many eyes make all bugs shallow" failed to replicate. (I understand this fate is even more common for anecdata than it is for formal studies.)
edit: amazing that I'm being downvoted for stating facts yet nobody replies to me.
My guess would be that you were being downvoted for spreading FUD and/or trolling.
The fact of the matter, is that Google usually publishes their source. They're just a bit slow at it. Most versions of android ship in binary form before source is released.
AOSP is fairly basic and somewhat limited on its own, unless you have the resources to replace all of the "gapps", including setting up your own app store. Google Play Services has been slowly taking over a lot of core (and not-so-core) phone functionality over the past year or more, and it's entirely closed source.
Google even stopped open-sourcing new versions of Google Authenticator, which you'd think would be a prime candidate for a full-blown open source project. (And hell, it's a crappy app; there are better GAuth-workalikes available.)
yet, they are just phasing all the important bits to privative code. Of course, this Android for work goes with Google Play, and guess what, it is privative, of course.
If your device is rooted, and by that I mean real rooted (bypassing SELinux), then it can get the encryption keys as at some point the data needs to be decrypted and viewable by you.
Encryption keys can be hidden in a way that is next to impossible to decipher. Superfish level of insecurity doesn't have to be the norm. The downside is that there are no open source libraries that make this possible which is why few people know about it.
That's obfuscation, which is just an arms race; it's not security in any measurable sense. It's fundamentally equivalent to the DRM problem. And there are no open-source libraries and not a lot of public documentation about how to defeat this sort of thing, so very few people who engage in this work have a good understanding of exactly how robust it is (and, anecdotally, most people tend to overestimate their products by a lot).
The one thing you can do is to put the key in a separate hardware device, and have the hardware refuse to make the key directly available, but only do encryption or decryption operations under certain circumstances (e.g. it's audited what's running on the device). This is definitely doable with a TPM on a standard PC, and there are in fact open-source libraries that will handle this for you.
Which brings a good point: if you have root (and presumably you can even write a different kernel), how do you make sure the TPM can verify what's actually running on the processor when you can just fake it?
Or better yet, if you have full blown root, what's preventing you from just kinda LD_PRELOAD some code for that process and steal the decrypted data before it gets to the legitimate application? Or take a screenshot.
So I think the point is that Google probably will not allow this to be ran on any ROM that's not signed by some key.
> if you have root (and presumably you can even write a different kernel), how do you make sure the TPM can verify what's actually running on the processor when you can just fake it?
On a PC architecture, the TPM is wired up to the CPU and other parts of the system, such that (for so-called "static root of trust") it gets initialized with a hash of the BIOS at bootup. The legitimate BIOS then adds in a hash of the boot sector, which adds in a hash of the kernel, which adds in a hash of anything the kernel thinks is worth verifying. Only if the final value of this TPM register (called a "PCR") matches up will the TPM allow a stored private key to be unlocked ("unsealed") and used.
Alternatively, for so-called "dynamic root of trust", there's a processor instruction that both clears all processor state (interrupts, paging, etc.) and a particular TPM PCR, and loads in a block of code. If the code is different, the key won't unseal. If someone is intercepting that processor instruction, the PCR won't get initialized correctly, and the key still won't unseal.
So it's mostly up to the kernel to verify everything that could possibly be relevant. (If you're thinking this is a hard engineering task, yes, that's one reason why this isn't in wide deployment, despite the technology all existing.) For instance, it might verify an entire read-only root filesystem, and then set things up so that on the work container or VM, nothing else can be installed, no additional executables or libraries or LD_PRELOADs get loaded, debuggers don't work, etc. In the personal-use container/VM, it can still run a normal OS.
OK. Let's assume that key lives on Google's servers. Then, Google must send it back to the Android device that it cannot trust unencrypted (possibly in a httpd session, but that is irrelevant for this discussion. The pipe may be secure, but you poor the data in a pool that isn't secure)
So we're all going to code, write, etc. on four inch screens?
Seriously why hasn't someone made a smart phone that "transforms" into a larger screen form factor when connected to a monitor? I could see Android phones doing this. I could never imagine iOS doing it-- Apple would never cannibalize Mac like that, and iOS is too jailed for anything "real."
Of course apps would have to support it. But those that didn't could pop up in little windows in "desktop mode." That would be fine.
Google should dump ChromeOS -- which I never understood -- and do this instead.
Android has been able to do this for years - here's video with details of someone using an android phone as a desktop replacement - with an external monitor and keyboard, etc...:
Also, ChromeOS is a functional replacement for Windows + Office: ChromeOS + Google Docs. It comes on hardware (ChromeBooks or ChromeBoxes) which are very cheap but capable, because ChromeOS is very lightweight. These devices are on par, cost wise, with a Windows Terminal - and require even less IT dept. effort to maintain.
Interesting video. It looks like the Chromecast can be used to mirror an Android phone's display, which might help with the HDMI vs USB connectivity trade-off.
So, with a Chromecast and Synergy, it may be possible to use a spare screen and your existing keyboard/mouse setup, keeping all your personal email and browsing off your work machine. And you'd only have to plug in USB for power.
> Seriously why hasn't someone made a smart phone that "transforms" into a larger screen form factor when connected to a monitor?
It has been done repeatedly. Motorola and Ubuntu come to mind. Both were failures.
I don't want my phone to turn into a desktop. Desktops are all about muscle, massive storage, gigabit connections, etc. Phones are about saving battery life.
Desktops don't mean any of those things, crappy old computers with none of your characteristics are very common.
Technology has improved significantly in the 3 - 4 years since Motorola made theirs, and Ubuntu's failed as a crowdsourcing campaign. Nothing has been proven.
I interpreted Ubuntu's failure more a statement of lack of confidence in the ability of Ubuntu to execute on this idea than as a statement against the idea's ultimate potential.
Samsung, Google, Apple, or Nokisoft (MS+Nokia) could do it.
I think Microsoft could be in a position to do this with Windows 10. It certainly seems to me like it would be the next logical step after the Surface Pro.
And phones in nearly all cases are limited by thermal profile. That's what keeps you from running at full tilt on a mobile device even when plugged in.
I like the basic idea of it, but I think their implementations were too soon. We aren't too far off now from where the only way high-end phone CPUs are behind low-end laptop CPUs is power consumption and heat dissipation.
Maybe in another 5 years, it'll only be a mobile CPU because the power consumption is ramped so far down. Then you could plug in a big cable and get enough power to run full speed, plus your gigabit connection, massive drives, multiple monitors, mouse, keyboard, etc. Heat might be a tougher one to solve though.
Or maybe we'll stick to syncing the data over the cloud instead and keeping the two platforms separate.
Android phones /do/ do this. Pretty much all the phones released in the past 3-4 years support one of the mobile monitor connection specs that'll send either a displayport or hdmi signal through the USB port. I've not personally used it much, but it's something that I do know some people use a considerable amount of the time for connecting to a larger monitor, giving presentations, etc.
The toolchain won't run on Android anyway. I would enjoy having, say, a Jolla or Ubuntu tablet that would run an Android toolchain.
ChromeOS is doing fine in the laptop/netbook form factor. Trying to unify the touch and pointing-device worlds is what made Microsoft late to the party.
I use AIDE and a git client on my tablet to read and run code. But it is a long way from having the refactoring, linting, and good error reporting of a highly mature Java IDE. Could be used to fix a problem in a pinch, but it would need tons of work to match Android Studio or Eclipse.
To be clear: you are saying the toolchain does run, but not to your liking?
It has been possible to install real Linux distros on Android for a while (X and all), with no root required. So you can install and run Android Studio if you so wish. It probably will be slow, but it can be done - today.
Sure, tech companies aren't going to start writing code on mobile devices. But there are plenty of enterprise companies where writing, viewing and editing can definitely be done on phones and larger form factors such as tablets.
Oh wow, can this be used to just create a separate profile for every app? That way I can run Uber or Line without giving them every permission to everything? This is the biggest reason I do not install apps. Every "famous" app requests so many permissions it's just stupid.
And not to mention the weirdness of some of them, like "WiFi Device Information". What's that mean? Access to my WiFi AP names? No thanks. Or just local multicast? Who knows.