Related
Hi,
I got a few spare androids' and i'm considering giving them to my kids (11 and 12) to play around with it and enjoy the android experience. however I don't want them being able to put 3rd party applications. how do i go about removing the option of "unknown sources" and maybe wifi from the settings.apk.
I'm not new to java and xml but sort of new to android development, I've tried several ways to remove it from the apk only (ark, ddx, baksmali, apksign) I did it in so many ways that i can't remember them all. I've also tried to decode the apk with apktool, ddx, baksmali, and creating a new project from existing source in eclipse, and I couldn't figure out what parts I have to modify to get it working (i kept on getting errors in eclipse so i wasn't even able to compile and test it in DDMS-eclipse).
Also i would like to know if maybe it is necessary to port the whole kernel source into eclipse?
I've searched all over the internet for a information for this specific thing and I couldn't find anything.
Btw, I'm using nix lucid.
Thanks In advance.
any help would be appreciated!
how about flash the supere rom without the google apps? that way they wont be able to access the market..
lagu805 said:
how about flash the supere rom without the google apps? that way they wont be able to access the market..
Click to expand...
Click to collapse
I know, the problem is not the market, i can pull it out from the phone with adb in a second w/o superE, but they can still install stuff on it with a sd card, and I would hate to not put in a file browser on the phone.
I think it would be a good idea to make a rom that's made for kids, for playing games and stuff without me worrying about it.
I'm sure that they will try to figure out a way to get around the "no market on the phone" and I should not underestimate a kid (even a 12 year old). I've seen him getting around lots of technological obstacle's.
I think that the world could use a kid's version of android, you know, get them hooked when they're young. The last thing i would like to hear from my kids is talking about iPhone or Windows. We're all linux in our house
Interesting. I too gave Magics to my 11 & 12 yr olds, one without a data plan and the other without a SIM at all. I think the right way might be multiuser like we already do on the desktops. Sudo would be a nice touch but I'd be happy to login as admin to install or whatnot.
Multiuser is something I'd like to see anyway with most or some settings on a per user basis. Or at least just for security, normal login can't do critical tasks that might cause issues. I think we'll hear about this again once we hear about some seriously dangerous apps/scams/viri on the phones.
In the meantime your best bet is education and rules about what can and can't be done. Then once per week or so you take the phone and check things out, update as needed, etc. So far my kids have little interest in breaking the rules and are happy browsing the market for fun things.
I think the only way to achieve this is to download the AOSP, edit the sources to remove the options and then compile your own ROM.
3rdcoast said:
Interesting. I too gave Magics to my 11 & 12 yr olds, one without a data plan and the other without a SIM at all. I think the right way might be multiuser like we already do on the desktops. Sudo would be a nice touch but I'd be happy to login as admin to install or whatnot.
Multiuser is something I'd like to see anyway with most or some settings on a per user basis. Or at least just for security, normal login can't do critical tasks that might cause issues. I think we'll hear about this again once we hear about some seriously dangerous apps/scams/viri on the phones.
In the meantime your best bet is education and rules about what can and can't be done. Then once per week or so you take the phone and check things out, update as needed, etc. So far my kids have little interest in breaking the rules and are happy browsing the market for fun things.
Click to expand...
Click to collapse
well, it is just a nix and SUDO should be possible, but setting this up is a quite a project and I don't think this is a one day project.
As for educating, I think they know right from wrong and I don't think that they will willingly break the rules, the market however is full of apps that are not meant for young kids..... what do you think they're going to do when they bump in to one of those apps? .
Actually what i wanted to do is to give them a phone with a line and no data plan so they can play games or watch movies, If the kids want to use the internet, there are more than enough boxes at home they can use. This phone is strictly for voice text and games.
What I want to accomplish in general, is having a child safe phone, and have the other parents here who want their kids to have to have an android, enjoy it. My way of giving back to the community.
But to have a phone that will be suitable for the purpose (not just for my kids) the data has to be completely disabled, and wifi is going to be the issue. putting on an encryption on wifi is a joke, ever heard of aircrack? I'm sure there are lots of determined horny 15 year olds that will get around that. (am i paranoid?)
Case_ said:
I think the only way to achieve this is to download the AOSP, edit the sources to remove the options and then compile your own ROM.
Click to expand...
Click to collapse
That's exactly what i want to do. The question is how do I do it?
Again, I'm not a complete noob, I just never played around with android as an OS. so if I can have the first push here here what I'm supposed to do to start this I would really appreciate it.
As I've said in my first post, I tried a few things and i couldn't get it right. what part of this don't i get??
Thanks a lot.
well your not even going in the right direction..
do you have an IDE with compiler and the android SDK all set up? then you can check on dferrera post on how to compile android from source... its listed in this forum.. please search
if your not a programmer or have no idea what classes - functions etc are then this might now be an option for you that is something you can be instructed on
you are going to need to learn to compile android from source and modify it, this is a very big task mate - be prepared, and no one can answer all the questions for u
alan090 said:
well your not even going in the right direction..
do you have an IDE with compiler and the android SDK all set up? then you can check on dferrera post on how to compile android from source... its listed in this forum.. please search
if your not a programmer or have no idea what classes - functions etc are then this might now be an option for you that is something you can be instructed on
you are going to need to learn to compile android from source and modify it, this is a very big task mate - be prepared, and no one can answer all the questions for u
Click to expand...
Click to collapse
Thanks for the reply, but i can't seem to get java5 working on 10.04 (the 10.04 repos have only java6 but i did add the old repos and ran in to some issues), I had it working on 9.04 though. anyone made it run on 10.04? or should I downgrade (or run it in VB) to 9.04/.10?
k50aker said:
Thanks for the reply, but i can't seem to get java5 working on 10.04 (the 10.04 repos have only java6 but i did add the old repos and ran in to some issues), I had it working on 9.04 though. anyone made it run on 10.04? or should I downgrade (or run it in VB) to 9.04/.10?
Click to expand...
Click to collapse
Add these 2 lines to the end of /etc/apt/sources.list file
Code:
deb http://pl.archive.ubuntu.com/ubuntu/ jaunty multiverse
deb http://pl.archive.ubuntu.com/ubuntu/ jaunty universe
then do:
Code:
sudo apt-get update
sudo apt-get install sun-java5-jdk
@k50aker
Hiding Wifi and other things should be quite easy task, but... how do you want to protect against system reinstallation? They could download any ROM from internet and install it in just 10 minutes. Backuping is easy too, so they could have 2 systems installed and switch between them when their dad comes home.
Android phones aren't desktops. You can't have root and don't give it to other users of a device.
Mod. edit: not dev related, moved to general
I wouldn't want to hide WiFI, the device is useless without connectivity, much cheaper toys out there for that if I wanted stand alone.
My two children each have a Magic and this is my experience, none of the worries that many parents seem to fear. They are well behaved and so far no problems and they are ready for 2.1 since 1.5 is just too confining even for them. Education goes a long way.
The best choice I made was to not put a SIM in one of the phones. WiFI is ideal since she is nearly always in a zone. This has gotten her used to IM instead of texting. Same effect but costs nothing. A SIP app works almost as well as SIM voice. Someday I'll do a data only SIM so she has total coverage, she'll understand that heavy data is to be done over WiFI and cell data is for VoIP and for times when it is really needed and can't wait.
However it would be nice if there was a limited setting requiring admin password for certain functions. But really, there hasn't been any problems but my kids might be grateful enough to not abuse the rights I give them. Best advice besides education if they are very young is to not SIM until after they get into the alternatives and not be addicted to texting. The older one has learned to watch her usage patterns and has to pay if she goes over budget.
Switch33 said:
Add these 2 lines to the end of /etc/apt/sources.list file
Code:
deb http://pl.archive.ubuntu.com/ubuntu/ jaunty multiverse
deb http://pl.archive.ubuntu.com/ubuntu/ jaunty universe
then do:
Code:
sudo apt-get update
sudo apt-get install sun-java5-jdk
Click to expand...
Click to collapse
those ropes are for jaunty not for lucid, and I have tried that before anyway and this is what i get:
Code:
desktop:~$ sudo apt-get install sun-java5-jdk
Reading package lists... Done
Building dependency tree
Reading state information... Done
sun-java5-jdk is already the newest version.
The following packages were automatically installed and are no longer required:
libwv2-4
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
1 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Setting up sun-java5-doc (1.5.0-19-0ubuntu0.9.04) ...
This package is an installer package, it does not actually contain the
J2SDK documentation. You will need to go download one of the
archives:
jdk-1_5_0-doc.zip jdk-1_5_0-doc-ja.zip
(choose the non-update version if this is the first installation).
Please visit
http://java.sun.com/j2se/1.5.0/download.html
now and download. The file should be owned by root.root and be copied
to /tmp.
[Press RETURN to try again, 'no' + RETURN to abort] no
Abort installation of J2SDK documentation
dpkg: error processing sun-java5-doc (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
sun-java5-doc
E: Sub-process /usr/bin/dpkg returned an error code (1)
Brut.all said:
@k50aker
Hiding Wifi and other things should be quite easy task, but... how do you want to protect against system reinstallation? They could download any ROM from internet and install it in just 10 minutes. Backuping is easy too, so they could have 2 systems installed and switch between them when their dad comes home.
Android phones aren't desktops. You can't have root and don't give it to other users of a device.
Click to expand...
Click to collapse
You are right, but one of the later steps I thought about would be a custom boot and custom or no recovery. But I will figure that out later in the project.
But i will probably change my direction on this (wifi etc.) based on what you guys say.
I need some info on getting a project going. I have been tasked to create an ATM type of application for the A500. It needs a minimal OS with only my program running, which uses a USB card reader and WiFi. The power is always connected and it is securely mounted. It's not, but think ATM.
I have read there are minimal OS source builds that we can get for this purpose. I haven't found where to get them, or what to Google for. Searching has found ROM's for other devices people have created. I have basically finished the program and now just need to get the system ready for install without a user being able to press the Home button or back button to get out of the program.
I'm too new to post in the dev forum, but I'm not a novice programmer. Ive done embedded dev, just not on android.
thanks
You could also PM some of the devs, they might be able to help you...
PMs
I hadn't thought of that, but I am too new on here to know who would be good to PM. Besides, I didn't want to bother busy people. But I'll continue to read up on the posts and see who seems to know what they are talking about.
Most decent Rom "modders" can strip most stuff out of the system. Heck, you can do it yourself with a little trial and error and a lot of time and patience.
Example, my newest mod in beta, has 2 services running at boot. Google services, and Keyboard. That's about as bare bones as one can get, and still maintain functionality and be called a tablet. Note that most apps, will have to be downloaded.
Anything past that, and you would need something like an old ASOP rom.
Hello Guys,
before I start: My apologies for this, I am not quite sure if I am even in the right Topic.
I think of myself as pretty new to Android, but got some experiences in Rooting, Custom Roms and such. But that is already as far as it gets.
Now my Problem: We lost our BES and now my Company decided to go with Android (SG4 I9505) and I have to make it happen :angel:.
1. I Need some Kind of Freeware tool to administer Android Devices (Basic: find device, delete data, restrict Apps)
2. If something like this dont exist (which I dont think-I just havent found it)), I would Need to know if I can use CM 10.2 as our Standard Rom and before you start rolling your eyes with experimental and such....
I have to restrict the phone solely to Telefone, Exchange and some preselected (mostly travel)Tools. NO GAPPS!!! and I think that nightly CM provides this with no problems
To realize this I downloaded the nightly from 18th, I think. I then added some APK´s into \System\app Folder and installed the ROM. This actually worked fine until I updated to phone afterwards via build in updating tool - all Tools were gone.(what did I miss?)
Now, our Standard is SG4 I-9505.
Any ideas on how I could do this? (I couldnt find what I was looking for)
1. Adminster a fleet of androids (free)
2. Customize a Custom ROM for corporate Identity (How to pre-setup Exchange Boot Logo, Lockscreen, etc.)
3. or customize a ROM to the Point it cannot do much except what is in the \System\app Folder and turn off updates
Any link is much appreciated. Sadly there is sooooo much andoid articles out there that I seem to get lost while searching for the right one. Thanks in advance!!!!
AccEss-dEniEd said:
1. Adminster a fleet of androids (free)
2. Customize a Custom ROM for corporate Identity (How to pre-setup Exchange Boot Logo, Lockscreen, etc.)
3. or customize a ROM to the Point it cannot do much except what is in the \System\app Folder and turn off updates
Click to expand...
Click to collapse
My guess is I'll get flamed for saying this - but here goes.
Android corporate (MDM) leaves a lot to be desired next to iOS, at least as far as I've been able to find. We manage a lot of iPads and obviously minus the custom ROM we've been able to do it all for little to no cost. We've shied away from Android a lot because of the limited MDM control.
But, since you asked:
1. Meraki Systems Manager (and the accompanying app from Google Play)
2. Good luck with that
3. See number 2
I think the reality is you're going to need to do something to the effect of either cook your own ROM and deploy it or use a tool like CWM to create an "image" that you would then restore to the devices. I did that with a batch of 60+ Nexus 7s and it worked out pretty well.
Edit:
With all that said - I would urge your management to reconsider their approach as the world has changed since Blackberry was the only game in town. Yes, still stick with MDM, device location, remote wipe etc. But unless you're dealing with highly sensitive information (exp banking), let people actually USE the device you're giving them. Don't lock it down to where its basically a first generation iPhone. I'm a big fan of giving someone a good tool and letting them use it the way that works best for them, while still keeping the device and more importantly the data under corporate control.
Assuming you have Exchange, does this not provide the management part?
AccEss-dEniEd said:
Hello Guys,
before I start: My apologies for this, I am not quite sure if I am even in the right Topic.
I think of myself as pretty new to Android, but got some experiences in Rooting, Custom Roms and such. But that is already as far as it gets.
Now my Problem: We lost our BES and now my Company decided to go with Android (SG4 I9505) and I have to make it happen :angel:.
1. I Need some Kind of Freeware tool to administer Android Devices (Basic: find device, delete data, restrict Apps)
2. If something like this dont exist (which I dont think-I just havent found it)), I would Need to know if I can use CM 10.2 as our Standard Rom and before you start rolling your eyes with experimental and such....
I have to restrict the phone solely to Telefone, Exchange and some preselected (mostly travel)Tools. NO GAPPS!!! and I think that nightly CM provides this with no problems
To realize this I downloaded the nightly from 18th, I think. I then added some APK´s into \System\app Folder and installed the ROM. This actually worked fine until I updated to phone afterwards via build in updating tool - all Tools were gone.(what did I miss?)
Now, our Standard is SG4 I-9505.
Any ideas on how I could do this? (I couldnt find what I was looking for)
1. Adminster a fleet of androids (free)
2. Customize a Custom ROM for corporate Identity (How to pre-setup Exchange Boot Logo, Lockscreen, etc.)
3. or customize a ROM to the Point it cannot do much except what is in the \System\app Folder and turn off updates
Any link is much appreciated. Sadly there is sooooo much andoid articles out there that I seem to get lost while searching for the right one. Thanks in advance!!!!
Click to expand...
Click to collapse
I currently work in the infrastructure of a good sized corporation. We're using IOS with a mixture of android hardware and there's some good news and bad news for what you want to do.
Good news is, like Jpcurrie said, exchange will handle remote wiping and locking the phone down. you can require the phone to use a PIN, remote wipe and and a bit more. As for locating the phone, Google actually has finally built in remote locating of your device and remote wipe as well. There's a couple good apps out there (lookout) will turn on your GPS and allow you to locate the phone and they're free. If you happen to have a virtualized environment with VMware, you could also use VMware View Horizons which builds in a secure sector on the phone and you can remotely manage which apps and files the user can use. the best part of View is you can use a BYOD model and keep corporate data secure. The biggest issue is if you don't happen to already use a VMware architecture it gets pricey quickly.
Here's the rub now. you want to install your own logos on the bootup which you could do by installing a custom ROM. This will void your warranty on the hardware and as it isn't 100% stable you'll be spending a LOT of time trying to keep a consistent environment.
Like netsyd said, talk to management about an MDM, and the branding of the devices, maybe even talk to them about using a BYOD to reduce costs of hardware and administration of that hardware.
Isn´t Knox supposed to allow administrators to only delete the data that belongs to the Corporate account (emails, calendars, tasks, etc.), or an administrator can still force a full device wipe? Sorry if the questions is too basic, I've tried searching around for info on Knox but couldn't find anything besides press releases.
I'm not a network administrator, I'm just a user and my school secure wifi installs a device administrator.
I'm sorry to deviate the topic a little bit from the original.
At Delta we use Air Watch but it's far from free. You can however manage devices and remote wipe. You can also view installed apps and remove what should not be there. Options for device profiles also. I help maintain these devices everyday. Not Free but an MDM is your best bet.
Sent from my SAMSUNG-SGH-I337 using xda app-developers app
long time - no see
Hiya,
sorry I didn t answer - kinda was overwhelmed with this Task.
Wanted still to thank you: I did what you suggestet and wanted to let you know where I am now.
1. Meraki = implemented - now runnning 160+ devices. (at no costs)
2. CM12.1 implemented (without GAPPS/no SU)
3. Standard Image/w Apps defined. (Mostly Offline capable Tools like "here" etc.(which actually reduced costs))
4. Since Android has limited capability to be administered in a "real" professional Fashion we mitigated this issue by creating a policy to forbid the user to temper with the device (e.g. Installation of Software/SU etc) yet to allow the Installation of Software manually by us via creating a ticket. We check the Software mainly for "sanity" and malware and install it if ok.
This has been working so far like a charm for us. None of the user were happy to loose the Gapps obviously - but once they had their Software and settled in, all was ok. For the Administering part: Meraki can tell me if Software is beeing installed without our Knowledge, also we see if SM doesnt speak with us anymore. So, for now, we got the most out of the System and I am happy to say: I got minimal Control in a Quality sense. No no more "KO Critera" - and we have implemented Android. Tracking etc. is forbidden in Germany anyway - so we use Meraki mainly to wipe if lost and to check if someone goes against policy.
What is still open:
- I am still working on a way to have the user enter his credentials and automatically enter These in all respective config files. (haven't had much luck - with the absense of SU obviously.
- a Little cosmetics still open (I am still trying to figure out how the theming really works ... I usually f**k up the Pictures and sounds.... but so far making Progress
- with less and less good Android devices coming out (now, I am probably beeing flamed now ) that suits our needs (open bootloader, known/supported CPUs, removable battery, SD Card Slot) - I think we might Switch by Q4/2016.
netsyd said:
My guess is I'll get flamed for saying this - but here goes.
Android corporate (MDM) leaves a lot to be desired next to iOS, at least as far as I've been able to find. We manage a lot of iPads and obviously minus the custom ROM we've been able to do it all for little to no cost. We've shied away from Android a lot because of the limited MDM control.
But, since you asked:
1. Meraki Systems Manager (and the accompanying app from Google Play)
2. Good luck with that
3. See number 2
I think the reality is you're going to need to do something to the effect of either cook your own ROM and deploy it or use a tool like CWM to create an "image" that you would then restore to the devices. I did that with a batch of 60+ Nexus 7s and it worked out pretty well.
Edit:
With all that said - I would urge your management to reconsider their approach as the world has changed since Blackberry was the only game in town. Yes, still stick with MDM, device location, remote wipe etc. But unless you're dealing with highly sensitive information (exp banking), let people actually USE the device you're giving them. Don't lock it down to where its basically a first generation iPhone. I'm a big fan of giving someone a good tool and letting them use it the way that works best for them, while still keeping the device and more importantly the data under corporate control.
Click to expand...
Click to collapse
Anybody else upset that you cannot root the device and install common linux shell utilities on it such as ssh, curl, etc? I created a petition for google to create a set of shell utilities for all android owners, regardless as root. Even without root, there is no reason we can't use ssh. This is common on most linux hosts. Please have a look and consider signing the petition, or give me feedback.
https://www.change.org/p/google-inc...utm_source=share_petition&utm_medium=copylink
nothing stops you from making this yourself, or using one of the existing ways to run a ssh server
Terminal IDE provides lots of GNU utilities, but hasn't been updated for 5.0 compatibility https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en
SSHDroid provides a SSH server https://play.google.com/store/apps/details?id=berserker.android.apps.sshdroid&hl=en
Hi #Sual, while you are correct, SSHDroid provides an SSHd server, However it does not provide a native ssh client, I could run through the connected device. I have tried many things suggested by users, but none of them offer a set of shell utilities I can run from the android host shell itself. Did you have a chance to read through the petition and fully understand what I'm requesting. Similar functionality would come from dan drowns android ports, or lil debi, or busybox, but all require root. Finally the fact things aren't updated for 5.0 compatibility, underscores that There is a reason that people desire this functionality on the device itself. Thanks for your feedback.
Saul Goodman said:
nothing stops you from making this yourself, or using one of the existing ways to run a ssh server
Terminal IDE provides lots of GNU utilities, but hasn't been updated for 5.0 compatibility https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en
SSHDroid provides a SSH server https://play.google.com/store/apps/details?id=berserker.android.apps.sshdroid&hl=en
Click to expand...
Click to collapse
There are ways to run Busybox without root. Here's an app that makes it dead simple: https://play.google.com/store/apps/details?id=burrows.apps.busybox. I've used it on my XT1528 (Verizon Moto E) with great success.
There are also ways to run Debian without root, like KBOX: http://kevinboone.net/kbox3.html
I couldn't read your petition because the link is bad.
But I don't know why this is something you feel is owed to you by Google. I agree that it'd be useful, but it's totally not something I'd expect to be part of a mobile platform at all. It's clearly something you could make on your own. If existing solutions require root, it's in part because that makes it easier or because their creators assume that everyone has root.
ecaslak said:
There are ways to run Busybox without root. Here's an app that makes it dead simple: https://play.google.com/store/apps/details?id=burrows.apps.busybox. I've used it on my XT1528 (Verizon Moto E) with great success.
There are also ways to run Debian without root, like KBOX: http://kevinboone.net/kbox3.html
Click to expand...
Click to collapse
Hi @ecaslak ,
I will try your suggestions. Most recently I've tried GNURoot Debian, which uses proot. However I was unable to use the open ssh server I installed on it. However, I will still stand by my petition.
A significant portion of the Android community spends great effort trying to root their devices, many with only the desire for common functionality that we have from any core linux distribution. While having root itself on a device would be great, it should be expected that google provide all device owners with basic functionality found in most core linux distributions for the last 20+ years. Not including an option for basic user utilities ( ssh / wget or curl / most of what is included in busybox, a fairly powerful common shell such as bash or similar ) , that most non-root accounts have on practically all systems, limits the freedom of expression and ability to create that users have come to expect from a GNU Linux distribution.
While root can be enjoyed on many devices, this is often only available to a small segment of the population who either pays a significant amount more for a unlocked device with a free bootloader, or spends a significant amount of time trying to root their device. Android does seem to provide a small set of simple userland utilities such as ls, cat, but not much beyond that. This is a request to provide a set of utilities similar to what is found on most any common Linux distribution.
While their is some concern for manufacturers or communication companies to lock their users devices down, there should be no concern allowing basic utilities on all android devices. To be specific, what harm does allowing somebody to download a file through a terminal using wget or curl, or to ssh into a host , or the phone itself? Similar functionality to these kind of operations are provided to developers in the form of the Android SDK, and or libraries and programs that can be installed on all android platforms. However having simple system shell utilities is quite different that writing an application. Then there should be no harm in making them more accessible to the Android community, in said form. Finally the communications companies will benefit from increased usage, and therefore data billings from providing these features.
This petition requests that Google compile / create / maintain / distribute a set of common linux shell utilities to be included with the device, or provided through the play store for all Android versions moving forward. The people who are signing this petition believe that any owner should be able to use common *nixy functionality on any personally owned android device, regardless of device manufacturer or communication company.
Furthermore, we believe that by creating a standard distribution for these tools will reduce the effort of many people doing the same thing in their own time. That a standard will improve the tools themselves, and improve the Android experience to the community at large.
Google Android has stood on the back of giants, and taken the Linux kernel and wrapped a nice system and SDK around it, with the exception of removing some of the core functionality included in most any Linux system. Thus Android is significantly limiting the freedom of users. This is a proposal for the middle ground, which will allow a better system for everyone, even people who have no root or unlocked device.
Finally I Had a look at the kbox project, I think this sentence from their site underscores the challenge users face:
"Android is not Linux, as Google repeatedly tells us — and getting ordinary Linux desktop utilities to work in Android can be a chore, to say the least."
Hi @sual, I believe change.org is having some issues with their servers the past few days. Sorry for the dead link. I re-posted above and found it working. I also pasted the petition arguments above. It is my belief that if enough people desire a feature, then it is reasonable to ask Google to provide such a feature. I think it's reasonable to create a petition for something you believe in. Finally I appreciate your feedback, and have considered your point of view.
Saul Goodman said:
I couldn't read your petition because the link is bad.
But I don't know why this is something you feel is owed to you by Google. I agree that it'd be useful, but it's totally not something I'd expect to be part of a mobile platform at all. It's clearly something you could make on your own. If existing solutions require root, it's in part because that makes it easier or because their creators assume that everyone has root.
Click to expand...
Click to collapse
Finally, another link in case the copy link from the change.org platform is broken.
https://www.change.org/p/google-inc...-linux-shell-comands-for-the-android-platform
Incredibly few Android users root. And Android is not a traditional Linux distribution; it's a mobile OS that happens to use the Linux kernel. GNU/Linux distributions contain all these common tools because large essential portions of them are written in scripting languages and because they are needed for operation of the system. These things are simply superfluous in Android.
Google hasn't removed any functionality from a Linux distribution in the building of Android. They build a totally different system using Linux as the kernel. and have no need to include other separate components that comprise a standard Unixlike environment Just like all kinds of other embedded devices do. In this sense, Linux is a commodity OS kernel that competes with other open-source and proprietary ones. Furthermore, Android in particular depends on non-POSIX mechanisms like wakelocks and SELinux and uses an unPOSIXlike approach to isolate different apps (different uid per app).
I suggest you start writing code or organize a project and recruit developers to build this.
@sual Developers have already built plenty of Android binaries. I can build em. Look here: http://dan.drown.org/android/ . There are busybox sets all over the play store. The problem remains that they are usually crippled if installed without root. Crippled beyond the point of what you can do with a user account in most Linux environments. I thought the desire for this would be greater, but maybe I'm just an odd fish. I should save up and look for a platform that meets my wants and needs.
If tools running as a non-root user on Android seem more crippled than a non-root user on a typical Linux distribution, it's because Android uses a different UID per app for isolation purposes. Which is a good thing. Hence the existence of the "system" user on Android, accessible via adb, which has many more permissions than available to any particular app. Making even this set of permissions more widely available to apps would be a security nightmare, there's a reason you have to deliberately turn on developer mode then again enable ADB, and a reason why you (afaik) have to have root if you want to enable ADB over wifi on the device itself.
With that said, you should be able to package your own tools and run them via the adb user on any Android device, no?
WARNING: This is not a place for you to come to say how great you think Chainfire is. I'm not calling his character into question, only his methodologies and the character of the outfit he sold out to (and I don't question the act of selling out, that's business, pays the bills, and puts kids through college). The debates about what people prefer and why are as old as the first software. And of course, I will not tell you what to do, no matter how much I disagree with you. If you UNDERSTAND what I have to say, then THIS software is for you. If you don't, you are probably better off with binaries.
The root situation on Android 5.x left a lot to be desired. There was basically just one distributor of a functional substitute user command (su), and it was binary. Recently, ownership of that binary and all of its history has become the property of a previously unknown legal entity called "Coding Code Mobile Technology LLC". While it was presented as a positive thing that that entity has a great involvement with android root control, this is actually a VERY frightening development.
The people at CCMT are no strangers to the root community. They have invested in, or own, a number of popular root apps (though I am not at liberty to disclose which ones) - chances are, you are running one of them right now. I believe SuperSU has found a good home there, and trust time will not prove me wrong.
Click to expand...
Click to collapse
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
You don't know the owners, and they are distributing a binary, so who the heck knows WHAT is going on.
Now a few important considerations with respect to your security and privacy;
1) Obfuscated binary cannot be sanely audited.
2) Function of this binary depends on the ability to manipulate selinux policies on the fly, including RELOADING the policy altogether and replacing it with something possibly completely different. Frankly, I've never heard a single reason why this should be necessary.
3) While a root control application may give you nice audits over other software that is using its service, it can *EASILY* lie about what it is doing itself. It can delete logs, it can share root with other applications that they have made deals with, it can directly sell you out to spammers, etc.
That is WAY too dangerous, and not worth the risk.
Frankly, you are safer if you disable selinux AND nosuid, and just run the old style of root where you set a copy of sh as 6755. And that is FRIGHTENINGLY dangerous.
So not satisfied with this state of root, and especially now with a new unknown entity trying to control the world, we bring you the rebirth of the ORIGINAL Superuser:
https://github.com/phhusson/Superuser
https://github.com/lbdroid/AOSP-SU-PATCH (this one is mine)
From the history of THAT Superuser:
http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html
Yes, look at the Superuser repo above and see whose space it was forked from.
Note: This is a work in progress, but working VERY well.
Use my patch against AOSP to generate a new boot.img, which includes the su binary.
Features:
1) selinux ENFORCING,
2) sepolicy can NOT be reloaded.
3) It is NOT necessary (or recommended) to modify your system partition. You can run this with dm-verity!
The source code is all open for you to audit. We have a lot of plans for this, and welcome suggestions, bug reports, and patches.
UPDATE NOVEMBER 19: We have a new github organization to... "organize" contributions to all of the related projects. It is available at https://github.com/seSuperuser
UPDATE2 NOVEMBER 19: We have relicensed the code. All future contributions will now be protected under GPLv3.
*** Regarding the license change; according to both the FSF and the Apache Foundation, GPLv3 (but not GPLv2) is forward compatible with the Apache License 2.0, which is the license we are coming from. http://www.apache.org/licenses/GPL-compatibility.html . What this means, is that it is *ILLEGAL* for anyone to take any portion of the code that is contributed from this point onward, and use it in a closed source project. We do this in order to guarantee that this VITAL piece of software will remain available for EVERYONE in perpetuity.
Added binaries to my the repo at https://github.com/lbdroid/AOSP-SU-PATCH/tree/master/bin https://github.com/seSuperuser/AOSP-SU-PATCH/tree/master/bin
These are *TEST* binaries ONLY. Its pretty solid. If you're going to root, this is definitely the best way to do so.
The boot.img has dm-verity and forced crypto OFF.
The idea is NOT to use as daily driver, while I can make no warranties at all regarding the integrity of the software, I use it myself, as do others, and its pretty good.
What I would like, is to have a few lots of people try it out and report on whether things WORK, or NOT.
IF NOT, as many details as possible about what happened, in particular, the kernel audit "adb shell dmesg | grep audit". On non-*nix host platforms that lack the grep command, you'll probably have to have to add quotes like this in order to use android's grep: "adb shell 'dmesg | grep audit'".
How to try:
0) Starting with a CLEAN system.img, get rid of supersu and all of its tentacles if you have it installed, if it was there, it will invalidate the tests.
1) Install the Superuser.apk. Its just a regular untrusted android application. Yes, there is a security hole here, since we aren't (yet) authenticating the communications between the android application and the binaries, or validating the application by signature, or anything else that would prevent someone from writing a bad Superuser.apk. This is on the list of things to do.
2) fastboot flash boot shamu-6.0-boot.img
3) test everything you can think of to see if it works as expected.
Note: there are some significant visual glitches in the android application, but nothing that makes it unusable.[/quote] @craigacgomez has been working on fixing up the UI. Its really paying off!!!
How you can reproduce this YOURSELF, which we RECOMMEND if you feel like daily driving it (in addition, make sure that you UNDERSTAND everything it does before you decide to do that, you are responsible for yourself;
You can build it any way you like, but I do my android userspace work in eclipse, so that is what I'm going to reference. Import the project from phhusson's git, including SUBMODULES. Right click the Superuser project --> Android Tools --> add native support. The library name you choose is irrelevant, since it won't actually build that library. Right click project again --> Build configurations --> Build all. This will produce two binaries under "libs", placeholder (which we won't be using), and su. You need the su binary. Then right click project again --> run as --> android application. This will build Superuser.apk, install it, and launch it.
Next:
repo init -u https://android.googlesource.com/platform/manifest -b android-6.0.0_r1
repo sync
Then apply su.patch from my git repo.
UNFORTUNATELY, the repo command isn't smart enough to apply a patch that it created itself. That means that you are going to have to split up the patch into the individual projects and apply them separately to the different repositories. This isn't that hard of a step though, since there are only FOUR repositories I've modified... build/ (this just makes it possible to build with a recent linux distro that doesn't have an old enough version of openjdk by using oraclejdk1.7. The boot.img doesn't actually need the jdk to install anyway -- its just part of the checking stage, so its up to you.), device/moto/shamu/, external/sepolicy/, system/core/.
After applying the patches, copy the su binary you generated with eclipse into device/moto/shamu/
Then ". build/envsetup.sh; lunch aosp_shamu-userdebug; make bootimage". That should take a minute or two to complete and you will have a boot.img built from source in out/target/product/shamu/
NEW UPDATE!!!!
While I haven't yet gotten around to running a complete cleanup (very important family stuff takes priority), I *HAVE* managed to find a half hour to get on with the Android-N program. If anybody takes a peek at the AOSP-SU-PATCH repository on the AOSP-N branch, you should find some interesting things there.
One warning first though... I updated the patches to apply against the N source code, and then updated some more to actually compile, and compiled it all. BUT HAVE NOT HAD THE OPPORTUNITY TO TEST IT YET.
Nice thing you came up. Sounds awesome.
We should have an alternate to all LLC thing, no matter how much respect (I owe you Chainfire thing) we got for the man who created CF Root (since Galaxy S days) and SupeeSU.
wow, tyvm for this! Will definitely test for ya and let you know.
I already applied your patch, built my own binaries and the boot.img but won't have a chance to test anything until tomorrow. Would love to get this %100 working fine and yeah, will use this from here on out instead of supersu.
Thanks again and yeah, will post when I have something ^^
I will be following progress closely, as should others. Without something like this, many in the community may naively let a corporate entity control root access on their devices. This is extremely frightening, it may not happen right away but if you believe the an entity will not monetize or exploit the current situation I believe you are sadly mistaken.
I could be wrong, however, it's not a risk I will take lightly and no one else should either.
Thanks for this.
Nice work!! Will be following this thread closely.
Time for me to learn eclipse. And do a heck of a lot more reading.
Larzzzz82 said:
Time for me to learn eclipse. And do a heck of a lot more reading.
Click to expand...
Click to collapse
Just note that I use eclipse because I'm used to it. Its become the "old" way for android dev.
i just paid for superSU is this the same people?
TheLoverMan said:
i just paid for superSU is this the same people?
Click to expand...
Click to collapse
I'm not sure what you are asking... are you asking if I am in any way affiliated with supersu, then you probably failed to read the first post in this thread altogether.
Charging money for a binary blob to use root on your device is borderline criminal, and unquestionably immoral. I'm sorry to hear that they got something out of you.
This is pretty great. I'll be watching this as well.
Perhaps this is not the place to take the tangent but why does root behave as it does and not more similar to a standard linux distro? It seems like it would be much more secure to have a sudo function as opposed to an all encompassing root. I'll admit I'm not that familiar with the inner working of the android OS but off hand I can't think of any program that absolutely needs to be automatically granted root every time it wants to run (I'm sure there are but even in this case the power user could chown it to standard root).
Wouldn't it be much more secure if you had to go in to developer options (which are already hidden by default) and turn on the option for sudo. This would then require a sudo-user password (perhaps even different than the standard lock screen password). Need to run a adblock update? Enter the password. Need to run Titanium backup? Enter the password... etc. Much more secure than a push of "accept".
Sorry for off topic but it's always made me wonder and seems like it would be root done right (see how I tied that back to the topic ) If elevating programs/tasks to a superuser was more secure perhaps it would not need to be such an issue...
^ Some root functionality is just too common for a Linux like sudo password to be usable at all. I'll give 2 examples:
1. Since Lollipop Google disabled access to mobile network settings for third party apps. Now it's only possible with root. I have an app that together with Tasker automates my network changing. That network app needs root access EVERY time there is any changes to the connected network and when it wants to change the settings.
Phone connects to a different cell tower? Root needed to detect this and determine the mobile network status.
You can figure how many times this is required per day.
2. I use Greenify to force some misbehaving apps to sleep after the screen goes off. It needs to request root every time it wants to sleep one of those apps. In other words every time I use them, after my screen goes off and I turn it back on I'd be facing both my secure lockscreen and the sudo password.
There's are plenty of other apps that need to request root access on a regular basis. These were just a few examples. If you only need root for TiBu then a sudo password type of security measure would work. In my case all I'd be doing with my phone would be typing that password again and again.
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
Sent from my Nexus 6 using Tapatalk
Interesting thread. Thanks for your work....subscribed
doitright said:
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
Click to expand...
Click to collapse
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.
I've read a few articles suggesting that they would prefer to prevent people from rooting their phones (partially so that they can monetise Android Pay - which requires a Trusted Computer Base, which means unrooted - as well as controlling Ad Blockers, which affect a revenue stream). I also suspect that only a tiny minority of Android users - and most of them are probably on here - actually root their devices.
Regardless of the motives, having a technological monoculture is never a good thing, especially when it is delivered as a binary owned by an unknown organisation.
(No disrespect to Chainfire - I have had many years of root access to my devices thanks to his efforts.)
scryan said:
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
Click to expand...
Click to collapse
Not quite.
"root" is the *name* of a privileged user, with user id of 0.
The "su" command (short for substitute user), is used to substitute your current user for another user, but most particularly root.
Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
Philip said:
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.
Click to expand...
Click to collapse
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
urrgevo said:
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
Click to expand...
Click to collapse
Nope. The root directory can be setup to be accessible by specific users just by applying the appropriate permissions to the files.
The root directory and root user are not specifically related.
doitright said:
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
Click to expand...
Click to collapse
Because the "third party" might actually be Google (or an organisation funded by them).
---------- Post added at 15:05 ---------- Previous post was at 15:02 ----------
doitright said:
Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
Click to expand...
Click to collapse
Shouldn't need to su to root to do this - that's what setuid and setgid are for.