Related
Team Cody!
Member List (in no particular order):
@thewisenerd
@omerjerk
@#Superuser
@dhrumangajjar
@navinn
@xaak
@Agaphetos
WANTED
- Testers - to beat the hell out of our ROMs
- Graphic Designers - boot logos, wallpapers, banners(one or two people)
- Themers - theme EVERYTHING!!!
- Co-Dev(s) - Do i really know what I'm doing most of the time (the answer to that is "probably not")
- Moral Support - LOL
- Suggestions - anything you got - Lay It On Meh!!
our works:
MiniCM9
CodyROM
CM9 Build #15
Evervolv
AOKP
OmniROM
AOSPA-legacy
note to self: add all the works, links
find a thread tagged [TeamCody], that's ours
Team-
@thewisenerd
@omerjerk
@#Superuser
@dhrumangajjar
@navinn
Source- https://www.github.com/CodyROM/
Blog- http://www.codyrom.wordpress.com/
Yea, we need support and suggestions!
todo list:
generalise this
First, finish the work on "reverse mounter"; as it is *technically speaking* easy (for me, to write scripts, that do things); and is pretty straight forward (no aimless edits or so)
fix gps in omni
fix video recording in omni
udpate twrp
switch to wlan0 in omni
random trolling lol
@thewisenerd
we should fix the date bug in notif bar..
is that xml derps..??
navinn said:
@thewisenerd
we should fix the date bug in notif bar..
is that xml derps..??
Click to expand...
Click to collapse
No, its a java derp
Compiling CM11/Kitkat for pico!
I assume you have knowledge of building with source, even if not, I don't really care (for there are a lot of guides).
First, get *all* the required packages installed. As for what I mean by *all*, is not really a question for me to answer. I used <insert-random-guide-from-xda> here, and the source.android.com's guide on initializing, just to be sure.
As for java, I use openjdk. *most* sources today support openjdk, elseways, either, you could force it to be compatible by removing just ONE line in build/core/main.mk
So, that's the packages part.
As for syncing sources, as most guides say, you DON'T need to use a ~/system folder or anything. You can use a folder, anywhere.
Just open up a shell, wherever you want to get the sources synced, and type in the following commands.
I assume you have the repo tool installed. IMHO, you should really create a "bin" folder in your homefolder (short linked as "~/") using the following commands:
Code:
mkdir -p ~/bin
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
Then, open up your ~/.bashrc file, using Geany (a better alternative to Gedit, perhaps ), using the command:
Code:
geany ~/.bashrc
Just insert this line, randomly (preferrably at the end of the file).
Code:
PATH=$PATH:/home/<insert-your-username>/bin
Now, for syncing sources. Make sure you are a directory above working folder.
Code:
mkdir -p <insert-ROM-name>
cd <insert-ROM-name>
Now, that you are inside the working folder, take your pick about the ROM that you are going to compile. This tutorial is for CM11, so i'd be running the following command.
Code:
repo init -u git://github.com/CyanogenMod/android.git -b cm-11.0
Yes, you can reference this from a cm10.2 source that you've already downloaded, and this will reduce the size required to download. Why, you could even reference this from an ICS source (just saying, not meant to be even tried).
If you aren't really building for mac, I'd suggest that you don't download the darwin repos.
Short way that I use:
Run following command in working folder.
Code:
mkdir -p .repo/local_manifests
grep "darwin" .repo/manifests/default.xml > .repo/local_manifests/local_manifest.xml
Open up local_manifest.xml using
Code:
geany .repo/local_manifests/local_manifest.xml
Add these lines on top:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
and the following line at end.
Code:
</manifest>
Now open up "search and replace" dialog box.
Search for:
Code:
<project
and replace with:
Code:
<remove-project
Voila, you've removed all the unnecessary darwin repos.
Now, for repo syncing.
I'd seriously suggest that if you live in parts of the world where the internet speeds are less than 1 m'b'ps (~128 k'B'ps (worst case, mine's around 60 k'B'ps, and I've known people with speeds ranging 30 k'B'ps), you'd sync just one repo at a time (the -jx).
run:
Code:
repo sync -j1
Else, if you have a super fast internet connection, please don't brag. Use a higher number, preferably 3, or 4.
Now, sync these repos, while I attend my classes. I'd return back and write part 2.
edit: part 2; go here: http://forum.xda-developers.com/showpost.php?p=49349691&postcount=8
Compiling CM11/Kitkat for pico! PART 2
reserved
Also, yes, you could use this localmanifest here: https://github.com/PicoKat/local_manifest/blob/dev/local_manifest.xml
but, you'd miss out the learning process
Anyways, this post would take up part 2 of the tutorial.
This is purely device specific. and, there's already a guide on android development section (of this device), the reason why I didn't make a new thread.
part 2 begins here:
Ok, so, you'd synced the repos?
Now, as opposed to roomservice, I'd prefer manually cloning the device tree, kernel, and vendors.
Clone a device tree (galaxyfreak's, or mine), into /device/htc/pico.
Clone the kernel sources from here: https://github.com/PicoKat/android_kernel_htc_pico
Clone the vendor tree from here: https://github.com/PicoKat/android_vendor_htc_pico
(note: if you are using my device tree, that has ION, you'd have to use my vendor tree, with updated blobs here: https://github.com/vineethraj49/android_vendor_htc_pico)
Ok, so that part's setup.
Now, lets move on to cherry-picking, and/or patching some stuff (from legaCyMod).
Note: you could have just added these to local_manifest too...
android_build:
Hopefully, you should know how to add remotes, and working with them, if not, click on the show content, below (as a sample for android_build):
Code:
git remote add legacymod git://github.com/legaCyMod/android_build.git
git fetch legacymod cm-11.0
git cherry-pick <commit-id>
where commit id's the looong "number" following /commit/ in the URL.
1. always rebuild build.prop
2. bringing back squisher
3. Removing TTS data
4. Revert adding auditd
5. add kitkat sdk versions
6. Revert "add drawables for all densities" (seriously, this saves space.)
7. adding support for our recovery
frameworks/av:
1. enable meta mode for video msm7x27a
2.bring back support for legacy omx
3. support legacy qcom audio variant
vendor/cm:
1. bring back squisher
2. revert adb authentication (yea, screw adb while dev'ving
3. remove ze bloats
Next, clone media-legacy to hardware/qcom/media-legacy, and display-legacy to hardware/qcom/display-legacy.
waait!!!!
You need to do some patches in some files. required to fix up camera.
patch two files, manually, making some sense out of this:
frameworks/base: https://github.com/szezso/vivo_cm11_patches/blob/d819363fe7d181e73841d3fa35c1b8c0c7d7c046/frameworks_base.patch
frameworks/av: https://github.com/szezso/vivo_cm11_patches/blob/2f1c87f4453c1c7c88e3c7d2b011994f894fe669/frameworks_av.patch
The next step:
Get prebuilts, seriously.
Code:
cd vendor/cm
./get-prebuilts
Then, "cd" back to root of source dir.
Run the following commands:
Code:
. build/envsetup.sh
brunch pico -j4
Hopefully, you should see an output package by the end of <insert-time-directly-propotional-to-crappiness-of-computer>
For batch-resizing bootanimation (in linux):
resizing part:
Code:
for file in *.png; do convert $file -resize 320x320! $file; done
you'd know which part to edit
for zip'ing part:
Code:
zip -r -y -q -0 bootanimation.zip *
will edit this later
Using CCahe
Now something very important who gonna compile ROMs, use CCache. It'll spped up the building process.
CCache - Compiler cache
How to use?
> Open a Terminal(Ctrl+Alt+T)
>
Code:
gedit /.bashrc
[You can use any alternative to gedit )
> Add the following lines to it:
Code:
export USE_CCACHE=1
export CCACHE_DIR=/[COLOR="Red"]source[/COLOR]/prebuilts/misc/linux-x86/ccache
Source here is the folder in which you have the code downloaded.
>
Code:
cd source
>
Code:
prebuilts/misc/linux-x86/ccache/ccache -M [COLOR="red"]25G[/COLOR]
25G = 25 GB of space to be used as CCache. You can use any value in this.
How does ccache work ?
Well , in short , what it does is that for C and C++ programs it caches the output. One it detects that the program is getting repeated it directly sends out the output and thus reduces the time of compilation.
After using ccache you will really feel the difference in the compilation speeds of your ROMs and kernels. //Copied.
Credits - Red Devil.
I use CCACHE, but the only difference is that I don't specify the directory. also, I did a "apt-get install ccache" long ago, and set file size according to that. Its still working just as fine.
and oh, yes, adding that USE_CCACHE=1 to .bashrc is required
IRC and you!
In case you came here via my signature, sorry for that. But really, you need to know some stuff about IRC, before going to a channel. The pico channel is #pico :fingers-crossed:
So, you might have heard about IRC, even logged into one (freenode, probably, the webclient of it), (and most probably saw that there was no activity and just closed that browser tab).
Let's take a timeout here to talk about IRC.
Instead of me talking about IRC, (and you being too lazy to Google stuff (not intended to those who solve problems themselves (not noobs (?) :wink: :wink)), here's a nice article by Rey Bango that you might want to read: IRC is Back: Here's Your Starter Guide
So, instead of me talking blah blah, and you skimming through most parts, which I assume, you did in the above article (considering you taking the energy to read it), here's what you need to know about Freenode:
..but in terms of development, from my experience, most developers tend to jump on Freenode - and rightfully so.
Click to expand...
Click to collapse
So, just to let you know, in those channels (where you thought there was no activity), there actually is a lot of discussion going on. You just don't know it yet.
So? What am I supposed to do? Keep a browser tab open? Don't expect me to say "Exactly not!" because that too is a viable option, though not very practically possible.
Here's where bouncers come in. Known as BNCs, here's what they do:
A bouncer (BNC for short) is a piece of software used to relay the communication between an IRC client and the network it is connected to, acting as a Proxy.
So, whats the point you ask? The reasons and benefits of using a bouncer are many and include hiding the real IP you are connecting from, protecting your nickname and channel from being taken on networks that don’t provide channel-/nickname registration and most of the time they’ll also notify you of private messages that came in when you’ve been disconnected – of course only when the bouncer can stay online being connected from a server.
Click to expand...
Click to collapse
Coming as either free or paid (either of them being useful, nonetheless), and cutting all the tech jargon, they allow you to "stay online" allowing you to close that browser tab you feared to keep open.
So, in case you actually read through the above quoted text, software!? Being connected from a server? Nah, just kidding. Here's where online BNC providers come in. They provide you a username, (and of course a password, which you need to select), and they host for you the BNC software (in most cases, ZNC).
Most BNCs allow caching of messages, i.e. buffered playback. Their servers are connected 24x7. You, the user, connect to their server, and through their server join the channels. You then, disconnect from their channel. Poof! But, their server still remains connected to the channels, and logs the messages in the channels, and any PMs sent to you. The next time you connect to their server, it gives you all the logged stuff, and it gets cleared. The next time you disconnect, ... Well, you get the flow.
Questions. That's what you go to IRCs for (mostly. I do it for the conversations ). How exactly do you ask questions? Similar to on XDA, but slightly different. I couldn't have said better than l3dx's answer on stackexchange:
Rule #1: Don't ask to ask
Rule #2: Behave as you would do in a real life conversation
Rule #3: Be patient. If there is no activity, it usually means that no one has read what you wrote yet. If no one responds, they don't know or didn't notice. You can re-try after a while, or ask if anyone has any clue with regards to your question x minutes ago.
Click to expand...
Click to collapse
What does Rule #1 mean?
Something very similar to what zxcdw said in the comments:
"Don't ask to ask. Just ask". Don't ask people "Anybody around?" or let alone highlight others to ask if they are around. It's just easier to drop your question, hang around and wait. Ask again in a few hours or so.
Click to expand...
Click to collapse
Also, use English, in most channels, if possible. Stay safe, don't open any unknown links or links to untested software, scripts and stuff. Stay safe.
IRC clients help you stay connected. A few simple google searches will get you going in the right direction. I personally use XChat IRC on Linux, but there are a lot of other good IRC clients available too.
Free bouncers should do, mostly. I use bnc.im, seen people using EliteBNC, some people installing ZNC in their own private servers that are online 24x7, YMMV.
That's about it for IRCs. Happy chatting!
P.S. Make sure you ask the right questions in the right channels.
sys2cache... something to help with less /system partition size.
note: this would be running at boot, with busybox, so,...
Code:
# algo:
# if read(switch_file=1)
# goto case 2.
# else case 1:
# get /system size
# get /data size
# get /cache size
# check /cache remaining size
# check for files in /system
# check for the following folders
# name generic size priority
# ./etc 3.1M 6
# ./vendor 36K 9
# ./addon.d 12K 8
# ./core 76K 7
# ./xbin 1.6M 5
# ./fonts 18M 1
# ./usr 21M 2
# ./media 4.8M 3
# ./bin 5.5M 4
#
# switch = 0;
# file folder_list;
# for i in list_args
# if (getsize($i) < getfreesize(/cache))
# mv $i /cache/$i
# mount bind /cache/$i /system/$i #fix syntax
# ifexists(/system/$i)
# switch = 1;
# folder_list >> $i
# else
# switch = 0; break;
# else
# echo "fak this, we're out of space!"
# fi
#
# echo $switch > switch_file
#
# sync; exit!
#
#
#
# case 2:
#
# for i in xargs(folder_list)
# do
# mount bind /cache/$i /system/$i #fix syntax
# done
#
# sync; exit!
#
#
#
# todo:
# * actually code this shiz
# * better error checking
# * add logging
Hey!
Make sure y'all check this!
http://team-cody.github.io/ :highfive:
welcome to another member @Agaphetos
Source- https://www.github.com/Team-Cody/
todo: update this post with website link.
lol, nvm this post
shameless bump.
since my board exams are over (sort of; only CS is left); i thought of building something for pico (a looong time since I did so).
Waht do I build?
At first thought; one *pure* CM9 build with *some* cherry-picks;
another; an updated CM11 build (updated sources and stuff)...
fixing up omx and stuff on Omni is on the "to-do" list and going to take some 'time' to do; so don't expect it to be fixed already :silly:
So; which one do I 'invest' time in? :cyclops:
@thewisenerd
MTP and OTG in cm9
Cm11 only if you can make it compressed
Sent from my Xperia S using XDA Free mobile app
mirhl said:
@thewisenerd
MTP and OTG in cm9
Cm11 only if you can make it compressed
Sent from my Xperia S using XDA Free mobile app
Click to expand...
Click to collapse
you mean MTP && USB tethering?
edit: a test build will be up today (if build goes well, that is).
edit: here you go: cm-9-20150315-UNOFFICIAL-pico.zip
thewisenerd said:
you mean MTP && USB tethering?
edit: a test build will be up today (if build goes well, that is).
edit: here you go: cm-9-20150315-UNOFFICIAL-pico.zip
Click to expand...
Click to collapse
This is one sick ROM - good job !!!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Clean | Stable | Flexible | Optimized | Excellent
-> ArchiDroid 2.X <- || Change to ArchiDroid 1.X
A Port of JustArchis Rom to our S3 LTE
Changelog
ArchiDroid 2.5.1
- ArchiDroid_Init code review
- ArchiDroid_RunOnce code review
- Fixed ArchiDroid backend not being executed in some scenarios
- Updated all ArchiDroid backend tools to latest versions
- Updated PA GAPPS to 8 July
- Reverted back to official Google PlayStore # This means that multi-dpi patch is not included anymore in the app itself, use xposed module or patch yourself
- PlayStoreFix is now included with Xposed
- App Settings is now included with Xposed
- Updated BetterBatteryStats to 1.16 RC5
- Updated XPrivacy to 2.1.24
- Updated GravityBox to 3.2.5
- Updated sources
Download
All Files Dev-Host
ArchiDroid-20140715-i9305-2.5.1-Experimental: ArchiDroid 2.5.1 Dev-Host, Mirror: Mediafire
Oldstable: ArchiDroid 2.4.6 Dev-Host
Remember that you don't need anything else to flash. Google Apps are included already.
Recovery-Philz_Touch_6.41.6: http://www.mediafire.com/download/?rf75pfrp34zws7b
Known Issues
All known and unknown CyanogenROM bugs (if any)
INSTALLATION INSTRUCTIONS
- Download the latest build of ArchiDroid ROM
1.- Wipe data / factory reset (mandatory if you coming from STOCK OR 4.2.X version or any other ROM)
2.- Install the Main ROM via Aroma installer, make your choices and lean back.
3.- Reboot
Attention: first boot will last a couple of minutes, at least almost 5 minutes or a few more. So after flashing take a rest and drink a coffee or a beer !
And after rom has booted up, led it settle a bit, till all apps and settings are initialized!
UPDATE INSTRUCTIONS
- Download the latest build of ArchiDroid ROM
- Take a nandroid backup
- Flash ROM using recovery and aroma installer
- Reboot
- Enjoy!
Known Bugs:
none...-> tell me if any.
In Aroma Installer you can select for example:
- 3 different Kernels: Boeffla, Angi and Cyanogen Stock
- different Launchers
- different Keyboards
- different Bootanimations
- many additional apps
- to add nav bar
and many other things
Follow ArchiDroid On XDA!
Write A Review!
Rate This Thread!
Buy JustArchi a Beer!
Like ArchiDroid On Facebook!
Hit Thanks!
XDA:DevDB Information
[ROM] [4.4.4. - KTU84P] [OmniROM] [GCC 4.8] [Experimental] [Flexible] [Excellent] [27/06/14] ArchiDroid V2.5.1 | Power In Your Hands, a ROM for the Samsung Galaxy S3 LTE I9305
This Rom is an official kanging of i9300 thread by @JustArchi lead developer and author of ArchiDroid ®. So all credits and thanks goes to JustArchi!!
Contributors
rodman01
ROM OS Version: 4.4.x KitKat
ROM Kernel: Linux 3.0.x
Based On: CyanogenROM / ArchiDroid / SelfKANG
Version Information
Status: Experimental
Created 2014-05-01
Last Updated 2014-07-15
[ROM] [XXUEMKC] [4.3] ArchiDroid V1.7.15 [25/05/14] & FAQs
Clean | Stable | Flexible | Optimized | Excellent
-> ArchiDroid 1.X <- || Change to ArchiDroid 2.X
INSTALLATION INSTRUCTIONS
Be aware that this ROM includes Knox!!!
So your counter will be increased to 1
- Download the latest build of ArchiDroid ROM
1.- Wipe data / factory reset (mandatory if you coming from STOCK OR 4.2.X version or any other ROM)
2.- Install the Main ROM via Aroma installer, make your choices and lean back.
3.- Reboot
4.- After rom is up, led it settle and start SU app to led it deactivate Knox
Changelog
Sammy_ArchiDroid 1.7.15
- Initial release
- removed S5 Theme, because of systemui fc
- Boeffla Kernel as default
Download
Download: Sammy_ArchiDroid-XXUEMKC Dev Host
Known Issues
All known and unknown Sammy bugs (if any)
Wifi strength is a bit low
[SIZE="+3"]ArchiDroid's FAQ / Q&A Section for i9300[/SIZE][SIZE="+1"]There is a special thread in the SIII section with and for FAQs. If you are interested in, I am sure there are good infos about the rom, for everybody and also related to our S1.[/SIZE]
[SIZE="+1"]Features / Why ArchiDroid?[/SIZE]
First of all, ArchiDroid includes everything available in it's base. The whole point of ArchiDroid is to improve the base, without needing of making any trade-offs, so by flashing ArchiDroid, you're getting everything offered by the base itself. There's nothing to lose, everything to gain.
You can read detailed information about every ArchiDroid component here. It's a massive wall of text, so I'm only going to list the core features without describing them.
These were written from scratch, they're completely unique and you won't find exactly the same implementation in any other ROM.
ArchiDroid-Unique features:
- ArchiDroid's AROMA Installer
- ArchiDroid's Pocket Debian
- ArchiDroid's Flasher
- ArchiDroid's RunOnce
- ArchiDroid's Init
- ArchiDroid's Backend Control
- ArchiDroid's Hardware Volatile Entropy Gathering and Expansion Daemon (Haveged)
- ArchiDroid's Fast Random Number Generator (Frandom)
- ArchiDroid's Adblock (dnsmasq/dnrd, dnsproxy2, pixelserv)
- ArchiDroid's Forced Update
Apart from that, here, on the credits page, you can find all third-party projects, which have been implemented into ArchiDroid. In addition to that, it's up to YOU to decide if you want to install something, or not.
ArchiDroid focuses on flexibility and user choice.
If you're looking for fastest ROM, choose ArchiDroid.
If you're looking for most battery-saving ROM, choose ArchiDroid
If you're looking for cutting-edge functions, choose ArchiDroid
If you're looking for the most flexible rom ever created, definitely choose ArchiDroid
ArchiDroid adjusts to your needs. You can make it whatever you want. With bunch of presets, modes and questions, you can make your ArchiDroid behave. Check yourself why ArchiDroid is The TOP 1 ROM for Galaxy S3http://forum.xda-developers.com/galaxy-s3#romList, according to number of followers, rates, reviews and downloads count. Check the Reviews, take a look at Video Reviews, do whatever you want to, ArchiDroid is proven to be one of the best ROMs for Galaxy S3, ever created.
Try ArchiDroid once, and you'll never look back. I can assure you.
Disclaimer
Developer's Kitchen
Unless stated otherwise, all ArchiDroid components are licensed under the Apache License:
Code:
Copyright 2014 [email protected]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Especially:
ArchiDroid is one of the most complex ROMs ever created. When you start digging in my work, you can very easily get lost. And I'm not talking about base itself, but about everything next to it. You can use every part of my work, as long as:
1. You include proper credit where you should. This usually includes proper comment in a script/file and in the credits of the project, including license (if needed)
2. You let me know about this fact. Through PM on xda or e-mail
I'm always happy to help, especially with the problems I faced in the past. However I also want to be respected, considering that most of the ArchiDroid parts were written from scratch.
ArchiDroid 2.X vs. ArchiDroid 1.X
The long battle between choosing over ArchiDroid 2.X and 1.X is still recent. There's no one real and true answer to this. It's up to YOU to decide who wins this battle, because obviously every user is different. I'm only going to give you some tips and briefly describe differences.
Despite the name, ArchiDroid 2.X and 1.X are totally different ROMs. It all started with ArchiDroid 1.X, a ROM based on Sammy's stock firmware, with all needed goodies and features baked in. Then eventually I managed to implement everything what I ever wanted to implement, therefore making ArchiDroid 1.X more or less complete. Then I started with ArchiDroid 2.X project, built from scratch from AOSP sources, with all source codes available.
The point is, ArchiDroid 1.X is more or less complete, there's no "real" development going on, as I obviously don't have samsung sources to begin fun with. On the other hand, ArchiDroid 2.X will never be finished, there's always something to improve, something to add, something to fix... This is ongoing process, which will reach the end when I finally break my SGS3 or change the phone to another one .
If you're new user or you don't know how AOSP works on our SGS3s then I highly suggest to flash ArchiDroid 1.X firstly. ArchiDroid 2.X is targeted at advanced users, who don't mind some "core" features being broken. It will NEVER be as stable as ArchiDroid 1.X is, so if stability is the number 1 for you, choose 1.X.
ArchiDroid comparision
From 1-10, based on my own point of view
Stability
2.X - 5
1.X - 8
Compatibility
2.X - 4
1.X - 9
Battery
2.X - 6
1.X - 9
Performance
2.X - 9
1.X - 6
Features
2.X - 9
1.X - 4
Android Updates
2.X - 9
1.X - 6
-----------
Overall
2.X - 42
1.X - 42
This is ArchiDroid comparision in a nutshell. If you ask me, I think that ArchiDroid 1.X is far better choice for daily driver, but if you're advanced user and you know how to deal with possible broken functions then you can have great time using ArchiDroid 2.X as well.
Remember that only ArchiDroid 1.X supports Samsungs-specific features, such as Smart Stay, Screen mirroring, Allshare or whatever. This also includes closed-source proprietary drivers, such as many bluetooth headsets, which won't work under open-source AOSP. Think twice before considering 2.X if you're addicted to these Samsung goodies.
On the other hand, ArchiDroid 2.X is the only ArchiDroid with "real" development going on, however all universal changes are also backported back to ArchiDroid 1.X, so you're not missing any feature, which benefits also Sammy's base.
That's it. I hope that a choice between both of these awesome roms is a bit easier now. If you still can't decide I suggest to flash both of them for some time and then decide which suits you better.
Know Your ArchiDroid
ArchiDroid is not only a rom. It's not only a baked android with third-party apps, modifications and tweaks. ArchiDroid is an universal backend which improves rom by many built-in functions.
Let me tell you a story. During developing first version of ArchiDroid 2.0 I experienced many problems, which were not that easy to solve. First of all - apps data. Trust me or not but you can't simply extract data, put it in /data/data after install and hope that it works. Android will detect such injection, report inconsistent of data and wipe everything attached to that. Okay so... How I should provide you with my boeffla preset? CoolTool settings? STweaks profile? If I put my data during flashing it'll get wiped. If I put my data and deny wiping it then Android will report inconsistent of data to user and work unstable. Yes guys, it's impossible to do so without a trick or without recompiling whole rom.
I won't tell you a whole story, because you probably don't want to hear about ArchiDroid development. I'll simply tell you that I overcome MANY difficulties, simply because I do what I like, and I like what I do. After countless number of hours, I can finally provide you with the ROM, which is the best. Why is it the best? Because I'm improving the base, and I'm not making any trade-offs.
Video Reviews / How ArchiDroid looks like?
@Koogly
@SkywalkerZ
ArchiDroid User Signatures
ArchiDroid Features
Know your ArchiDroid, learn how to use it
Introduction / Basics
Welcome to ArchiDroid's world mortal. In this tutorial we will show you what ArchiDroid has "inside" and what it really offers. All of things included in this post are ArchiDroid-specific, which means that you won't find any ROM with the same features, as they're written from scratch.
Here you can find some definitions of the words used in sections below. You should know most of them, but in case somebody is lost here you can get back on track.
Terminal, Shell - Typical android shell, which may be obtained in three ways.
1. Through native Android Debug Bridge (ADB) with command "adb shell" from the PC or even "ADB through network" (if supported).
2. Through any Android terminal app, f.e. Android Terminal Emulator bundled with ArchiDroid.
3. Through secure shell daemon (sshd), which needs to be turned on firstly. This is extremely useful in terms of pocket debian, which will be described later.
You can use any of these methods to access android's terminal, however usually Android Terminal Emulator will be the easiest one, as it's android app bundled with ArchiDroid. WARNING! Most of the commands below WILL require root access. You can log in to super user shell by "su" command right after obtaining shell. If you're unsure if you're logged as root or not, "whoami" command should print actual user, "root" or "unknown uid 0" are OK, others are not.
ArchiDroid's Pocket Debian
From wikipedia:
From debian site:
How exactly this covers our beloved SGS3 (and countless number of other android arm-based phones)?
As you may (or even should!) know, Android operates on it's own Linux-based kernel. Android's kernel is literally a fork of Linux kernel, with a few special/unique functions which are required, mostly hardware-specific. Because of that kernel itself is VERY compatible with everything based on Linux.
However there have always existed one typical problem, lack of proper environment. We have a great kernel, great power, linux-based android environment, but this environment lacks of very common and required libraries/binaries. If you ever wondered what is or what does busybox, this is the answer. Busybox is just a small package which offers a few standalone GNU/Linux binaries, which are required to make certain things work. For example, swap priorities. Android knows what swap is, and nothing else. It doesn't know that swap could have a priority, so if you use android's swapon command on 4 devices, it will firstly fill first device, and then proceed to the next. That's why we need busybox in ALL custom kernels, because android environment isn't enough.
However busybox sometimes isn't enough. If we focus only on Android itself, it is. But if you for example want to run stricly linux-based service, I don't know, a web server for example... Is it possible to run a native linux web server on an android? No, it's not. You should firstly compile such service on arm architecture, including all dynamic and static libraries (wrrr ) in it only to finally get mad because of missing libraries or other dependencies. Of course if you're patient you'd finally compile everything and set up, however how long would it take? A few days maybe? If you're skilled in what you're doing...
This is why I included built-in "pocket" debian in ArchiDroid. It's FULLY compatible with everything compiled/based on armhf/armel GNU/Linux architecture, for example Raspberry Pi. With two easy commands you can literally jump into debian environment and use every typical GNU/Linux utilities known from debian itself. Of course this means nothing for most of the users, because they'll never have any reason to use such debian environment but from the developer side, it's big step forward. The best example is with github. As you know ArchiDroid has it's own repo on github, from where you can download/manage stuff. There also exists git app for linux and windows. If you want to follow "expert" way of flashing experimental ArchiDroid version, such program is required. The scenario is the same as compiling web server for an android, it requires much more effort than it's worth. And even then you can end up with syncing external dependencies and searching for solutions for the problems you've never seen before... And with ArchiDroid's pocket debian? It's as simple as in any debian/ubuntu distro. "apt-get update && apt-get install git" and voila. Your git is installed and ready for work. Going further I've even included git in pocket debian itself. Okay, I have debian, I have git, and what next? With git utility I can for example provide you with delta updates for ArchiDroid! ArchiDroid can easily use pocket debian to set up and sync ArchiDroid's repository and then pack and flash latest version without even needing of a PC, using 7-zip or anything else. Another example? A web server. I know that it's very dev-specific but if you for any reason need a web server running, just for example to test simple website, you can have it with just one command. Going further, VNC? MySQL server? PHP? Python? Perl? Ruby? Maybe conditional tasks with cron? Persistent minimal IRC client? rtorrent with rutorrent GUI over WWW? The list goes on... Anything based on linux will work. You can even host a server for your favourite game, as long as it has armhf/armel binaries (unfortunately most of the games don't).
So that's it. In short, debian is an operating system built-in in ArchiDroid to provide you with (unfortunately missing) GNU/Linux environment, with full power, ready to handle anything you could request. I made my best to include fully working debian in ArchiDroid for a minimal cost. Whole OS is packed in one big tar file, compressed using highest bzip2. As for now pocket debian has ONLY 40 megabytes of size, maybe in future it will have up to 50 megabytes, but no more. It's a VERY small cost for having such great power, especially if you know how to use it.
This is a really cutting-edge feature, mostly because I have no limitiations what I can include in my ROM right now, and while other developers are dealing with OpenDelta updates and many Android-based problems, I'm just launching my pocket debian and manages linux stuff.
I'm SURE that most of the advanced ArchiDroid user will just LOVE this feature, as much as I love it. I'm looking forward to your responses how YOU use pocket debian with your ArchiDroid. It's also a great time to learn what does the debian offer and how you can simplify your common tasks with just one example debian utility .
Technical informations:
1. Pocket Debian does not cause any additional overhead. We don't need to use emulation, neither virtualization to boot our monster. I used chroot technology to "jump" into debian environment with already running kernel and Android. That means additional required CPU/RAM is based on what you run in pocket debian. Booting itself doesn't require anything, just about one megabyte of ram for /bin/bash shell .
2. Android has some restrictions, mostly sockets. It doesn't allow to create inet sockets by default, even for root users. You will need to add your custom debian users to special group called "inet" (GID 3003) to allow creating of inet sockets, and you may also need to add a group to net_raw group (GID 3004) to allow creating of raw sockets. Please keep in mind that it's only required if you're running an app which required it's own socket, for example mysql server. So apt-get install mysql-server will fail right after booting, you will need to use "addgroup mysql inet" and then apt-get -f install to complete installation. Of course "mysql" is the new user under which mysql-server really operates. I've added root to both of these groups by default.
3. The only "real" restriction is the kernel. Our debian uses Android kernel and it's filesystem. It should work with most common tasks but in some cases our kernel may lack specific modules or built-in code, for example tun/tap required for OpenVPN. Still it's enough to run pretty much everything and if you get in touch with your favourite kernel developer you can also kindly ask for specific missing things.
4. Debian is built and included thanks to debootstrap utility, ArchiDroid command used for creating debian environment is debootstrap --verbose --arch armhf --include=git,ca-certificates,ssh,htop,tightvncserver,xterm,xfonts-base --exclude=manpages,man-db,rsyslog,vim-common,vim-tiny testing debian http://ftp.fr.debian.org/debian
HowTo:
Pocket Debian contains two main terminal commands, "adlinux" and "debian". Both of them are described below. By adlinux and debian you boot and jump into debian's chroot, which means you can use any debian-specific commands.
Examples:
passwd - changes password of actual user. This is needed to login as specific user, for example through ssh.
service ssh start - starts local SSH (secure shell) daemon on native port :22, to which you can easily access via any client supporting ssh, f.e. PuTTY. So basicly after you start shell you can literally connect to your local area network (LAN) IP on port 22 f.e. through PuTTY from your PC.
ifconfig - prints network-related informations about online interfaces, including your local IP, which may be useful for connecting to SSH.
htop - Enhanced top utility. Gives you very good terminal-based view on actual running processes, used ram, load, and more.
apt-get update - Syncs with debian's apt repository. This is mandatory to use many of apt commands because ArchiDroid's debian comes without local repo available, however fully configured to download and access it with just one command
apt-get install XXX - installs packet XXX from debian's repository.
apt-cache search XXX - searches for all packets including keyword "XXX". Ultra useful in terms of searching for specific packet.
Please note that pocket debian is VERY similar to normal native Debian/Ubuntu distribution, therefore above commands are not ArchiDroid's magic, they're very widely used in Debian/Ubuntu distros. If you want to learn more, most of the Debian/Ubuntu tutorials will be very helpful.
ArchiDroid's Pocket Debian Booter (adlinux)
You can call "adlinux" command from your favourite terminal.
adlinux is designed to boot and prepare ArchiDroid's Pocket Debian environment. It requires mode to be specified, and also respects any extra arguments passed.
If you call standalone "adlinux" command then it will print usage and then ask you what you want to do with giving proper informations about every choice. Additionally if you know what you want to do, you can also pass arguments directly to adlinux command, f.e. by executing "adlinux default", which will execute adlinux with "default" mode.
Available modes:
default - Will mount /data /system /storage/sdcard0 /storage/sdcard1 and core filesystems in chroot. Default suggested mode
safe - Will mount only core filesystems in chroot. Useful if you don't want to share your storage in chroot
bare - Won't mount even core filesystems such as /proc /dev or /sys. Requires "debian force" to enter chroot. This is the "real" safe mode. You won't be able to interact with an android in any way, while debian itself will work in very limited environment, making core functions unavailable. Suggested only for testing purposes
rebuild - Will automatically reboot your device and remove debian folder in the safe way. WILL CAUSE ALL DEBIAN DATA TO BE LOST!
unmount - Will automatically reboot your device to safely unmount debian environment
Extra options:
extsd - Use external sd card (/storage/sdcard1 /storage/extSdCard), if possible
intsd - Use internal sd card (/data/media/0)
Additional information about modes:
Debian shares core kernel filesystems in "safe" and "default" modes, while it also shares your internal and external sd card in "default" mode. This is nothing to be scared of, as you have full control of what you run in debian, however please note that you CAN'T do whatever you want. All mounted partitions in debian are "binded". "Bind" means that it's mirrored to the mount point and all changes on mounted partition WILL affect the mount point, which is logical. This is nothing to be scared of, as long as you know that debian only extends your environment, it does not fully works in it's own and you CAN cause serious problems from inside of chroot. The only really safe mode is "bare" mode, however in "bare" mode debian can't really do anything, as kernel filesystems are absolutely required for most of the functions. Okay so, you need to know one thing. If you have booted debian you SHOULD NOT touch debian's folder, which is ArchiDroid/debian (on your internal or external sd card, depends what you choosed).. As you know debian for example binds /data to it's folder /data, which is physically ArchiDroid/debian/data. If you for example delete ArchiDroid/debian through root explorer WITH mounted debian then it will ALSO delete debian/data folder, which is binded to /data, and therefore will delete your whole internal sd card, that's why it's extremely important to take care because booted debian becomes part of the android and deleting it can cause at least soft bricks, with a possibility of hard as well. If you want to delete debian folder PLEASE use "rebuild" mode, only through this way you're absolutely sure that nothing bad happens and you won't delete your whole system partition by accident.
Note about extsd option:
Debian requires symlink functionality, typically native windows filesystems DON'T support symlinks, therefore you need to have your external sd card formatted in one of the native linux filesystems, f.e. ext4. adlinux will automatically tell you if debian can be unpacked and used on your external sd card, however it won't be possible under most common filesystems, such as exFAT or FAT32.
Technical informations:
1. Pocket debian archive is located in ArchiDroid/System/debian.tar.gz file. This is "bare" system used for creating environment for the first time, you should not touch it.
2. adlinux detects if debian is already extracted when booting, if not, it's firstly extracted from the file described above.
3. After extracting (if required), core filesystems are mounted with "bind" option based on the mode you've selected in "mode" question above. Typically it mounts /data /system /storage/sdcard0 /storage/sdcard1 /storage/extSdCard /dev /proc /sys.
4. Unmounting is not fully supported right now (linux barrier), therefore both "unmount" and "rebuild" options require a restart to execute properly.
ArchiDroid's Pocket Debian Shell/Chroot (debian)
You can call "debian" command from your favourite terminal.
debian command is designed to allow you "jumping" into debian chroot created by adlinux. Please read how adlinux command works firstly if you haven't done that already. debian command checks if core filesystems are available (if debian is booted), and if they are then it firstly modifies required environment variables to make debian happy (such as TERM, HOME, PATH), then it changes root (chroots) into debian folder, therefore allowing you to execute everything from inside of chroot. It's very generic command, therefore standalone "debian" command won't give you a choice the way adlinux did.
Available options (parameters):
force - required for jumping into bare debian, created with "adlinux bare" command above. This skips debian checks for mounted core filesystems, normally you should avoid it at all cost, unless you know what you're doing. If core filesystems are missing then it's very likely that your debian will be disabled in more than 90%.
extsd - Use external sd card (/storage/sdcard1 /storage/extSdCard), if possible
intsd - Use internal sd card (/data/media/0)
cmd - Executes command in debian chroot
WARNING! cmd parameter will cause all further parameters to be threated as a command passed to debian, therefore you need to make sure that this is the last debian parameter which you want. For example "debian force cmd service ssh start" will skip filesystems checks and execute "service ssh start" in debian's chroot, however "debian cmd force service ssh start" will pass "force service ssh start" to debian, therefore respecting filesystems checks and passing invalid command.
This function is extremely useful for making init.d and other startup scripts. For example you can easily call "adlinux default" and then "debian cmd service ssh start" to call secure shell daemon on every boot with two easy steps.
Technical informations:
1. debian command uses chroot technology to change root of current shell to debian shell.
2. After chrooting to debian directory, /bin/bash shell is automatically called as default debian shell.
ArchiDroid's Flasher (adflash)
You can call "adflash" command from your favourite terminal.
adflash is a great small utility, which allows you to easily update your ArchiDroid to latest stable or experimental version with one easy command and delta upgrade. It utilizes ArchiDroid functions, therefore you must be running ArchiDroid to use it.
If you call standalone "adflash" command then it will print usage and then ask you what you want to do with giving proper informations about every choice. Additionally if you know what you want to do, you can also pass arguments directly to adflash command, f.e. by executing "adflash 2e git", which will execute adflash with 2.X-EXPERIMENTAL version using git mode.
Available versions:
2e - 2.X-EXPERIMENTAL
2s - 2.X-STABLE
1e - 1.X-EXPERIMENTAL
1s - 1.X-STABLE
Extra options:
git - Sets up local git repository, which gives you delta upgrades and bandwidth saving
direct - Downloads targeted branch as .zip file directly from github
clean - Cleans everything up, including local repo and tmp folder from ArchiDroid directory specified below
extsd - Use external sd card (/storage/sdcard1 /storage/extSdCard)
intsd - Use internal sd card (/data/media/0)
nozip - Shows changelog and changes only
Okay so, the most interesting option is the mode...
Direct mode is simple, fast and effective. It downloads target version (stable or experimental) from GitHub server, then it repacks downloaded zip file and makes it available for flash. You should use this mode for one-time downloads, such as once per stable version or two. The only advantage of this method is the ability to download from github (and with one command).
Git mode is complex. It uses ArchiDroid's Pocket Debian (read above) for cloning and updating local ArchiDroid repo. This gives several number of advantages, mostly for using experimental versions. Firstly, by having local ArchiDroid repo you have to download ONLY changes between your snapshot and server's snapshot, which means delta upgrades. Secondly, you have access to all commits from target branch, so you know exactly what has changed since your latest download. Again, this is extremely useful for experimental branch, as changelog may not be up-to-date. Keep in mind that git mode will require additional space on your device for keeping ArchiDroid repository, therefore you sacrifice some space for delta upgrades. This mode is extremely useful for flashing ArchiDroid often, for example daily experimental versions, because in fact you download only new commits instead of whole repo/archive.
ArchiDroid's RunOnce (Backend)
ArchiDroid's Init (Backend)
ArchiDroid's Backend Control
ArchiDroid Backend Control is a set of settings, which controls behaviour of ArchiDroid's Init. It's located in /system/archidroid/dev and contains a number of files, which are recognized by ArchiDroid's Init. You shouldn't directly touch /system/archidroid/dev, instead you can control behaviour of ArchiDroid's Backend through /system/archidroid/scripts. They can be easily executed through any script manager, f.e. Root Browser or Android Terminal Emulator. Some of the settings are also located in /system/archidroid/etc folder, mostly configurations for binaries utilized by ArchiDroid's Init.
ArchiDroid's HArdware Volatile Entropy Gathering and Expansion Daemon (Haveged)
The haveged project is an attempt to provide an easy-to-use, unpredictable random number generator based upon an adaptation of the HAVEGE algorithm. Haveged was created to remedy low-entropy conditions in the Linux random device that can occur under some workloads, especially on headless servers. Current development of haveged is directed towards improving overall reliablity and adaptability while minimizing the barriers to using haveged for other tasks.
The original HAVEGE research dates back to 2003 and much of the original haveged documentation is now quite dated. Recent work on haveged has included an effort to provide more recent information on the project and its applications.
The original research behind HAVEGE use was based upon studies of the behavior of processor caches from a hardware level. The 'Flutter' documents attempt to provide a modern view of HAVEGE at software level through the use of a diagnostic build of haveged that captures the non deterministic inputs to haveged for analysis by external tools.
ArchiDroid has built-in haveged entropy generator. It's controlable through ArchiDroid's Backend Control - ArchiDroid_Haveged_EnableDisable.sh. It's turned on in default configuration, through HAVEGED_ENABLED
ArchiDroid's Fast Random Number Generator (Frandom)
Frandom is a Linux kernel random number generator, which is 10-50 times faster than what you get from Linux' built-in /dev/urandom. And it uses very little (/dev/frandom) or none (/dev/erandom) of the kernel's entropy pool, so it is very useful for applications that require a handy source for lots of random data.
ArchiDroid has built-in frandom activator. It's controlable through ArchiDroid's Backend Control - ArchiDroid_Frandom_EnableDisable.sh. It's turned on in default configuration, through FRANDOM_ENABLED.
Notice: Kernel must support frandom module to actually make use of that. Init will try to search for frandom.ko module and load it, then use /dev/erandom for both /dev/random and /dev/urandom. If your kernel supports frandom, it will work. If it doesn't, obviously this will be skipped even if you have FRANDOM_ENABLED. Check ArchiDroid Init log located in /data/media/0/ArchiDroid/Init.log to check if frandom works properly for you.
ArchiDroid's Adblock (dnsmasq/dnrd, dnsproxy2, pixelserv)
dnsproxy2 is a replacement DNS proxy for Android 4.3+
This currently allows the user to manually override the DNS server IP,
and it sets the correct UID on outbound requests so they can be filtered
via iptables / AFWall+ / DroidWall / etc.
Dnsmasq is a lightweight server designed to provide DNS, DHCP and TFTP services to a small-scale network. It can serve the names of local machines which are not in the global DNS. The DHCP server integrates with the DNS server and allows machines with DHCP-allocated addresses to appear in the DNS with names configured either in each host or in a central configuration file. Dnsmasq supports static and dynamic DHCP leases and BOOTP for network booting of diskless machines.
Dnrd, Domain Name Relay Daemon is a caching, forwarding DNS proxy server. Most useful on vpn or dialup firewalls but it is also a nice DNS cache for minor networks and workstations.
Pixelserv is a super minimal webserver, it's one and only purpose is serving a 1x1 pixel transparent gif file. Using some creative firewalling (netfilter/iptables) rules you can redirect some webrequests (for adds for example) to pixelserv.
ArchiDroid has built-in Adblock. It's controlable through ArchiDroid's Backend Control:
ArchiDroid_Adblock_DnsmasqDnrdModeSwitch.sh
ArchiDroid_Adblock_EnableDisable.sh
ArchiDroid_Adblock_EnableDisableLocalDNSes.sh
ArchiDroid_Adblock_EnableDisableLocalDNSesDaemon.sh
ArchiDroid_Adblock_LockUnlockHosts.sh
ArchiDroid_Adblock_MoabAdawayHostsSwitch.sh
ArchiDroid_Adblock_Reload.sh
It's turned on in default configuration, through:
ADBLOCK_ENABLED
ADBLOCK_LOCAL_DNSES_DAEMON_ENABLED
ADBLOCK_LOCAL_DNSES_ENABLED
ADBLOCK_USE_ADAWAY_HOSTS
ADBLOCK_USE_DNSMASQ
In short. This is a very advanced and powerful solution for blocking ads through DNS queries. First of all we're forwarding all DNS traffic to localhost (127.0.0.1). Then we're handling them through local DNS server - dnsmasq (default), or dnrd (option). Our local DNS server reads blocked hostnames through special /system/archidroid/etc/hosts file, then if no record is found, it forwards DNS query to OpenDNS/Google DNS servers, or if it's found, returns 127.0.0.1 as the address. Lastly, pixelserv is providing a 1x1 NULLGIF response on local web server, so instead of big black/white screen instead of the AD, we get 1x1 transparent pixel, which usually perfectly hides ad from the app or the website.
Extra features:
1. You can specify if you want to use dnsmasq (default), or dnrd (option) as a local dns server. Dnsmasq is more flexible, modern, faster and has less memory footprint, however I also left dnrd as an option, because it's proven to work stable.
2. You can specify hosts file, which you want to use. In default configuration we use AdAway's hosts file, with more than 30 thousand of records, which results in extra ~2.5 MB memory usage. You have also an option to use MOAB (Mother Of Ad Blocking) hosts file, with more than 330 thousand of records, which will result in about ~30 MB memory usage. Eventually you can append your own rules or use non-standard hosts file, available in /system/archidroid/etc/hosts. Pro tip: You can point AdAway to use this hosts file (/system/archidroid/etc/hosts_adaway), which will result in automatic updates. /system/archidroid/etc/hosts is a symbolic link, either to hosts_away or hosts_moab, if you want to specify your own hosts, you can delete symbolic link and write your own rules.
3. Original /system/etc/hosts file has been locked from editing. This is to ensure that AdAway or other adblockers won't use obsolete and slow method of blocking ads through hosts. The whole point of implementing Adblock in ArchiDroid is to provide you with super-fast, flexible and effective way of blocking ads, also with getting rid of black/white ad screen. In 99% situations you don't want to touch ArchiDroid's default behaviour, as it blocks ads perfectly. Eventually, if you have a very good reason, you can unlock original hosts file through ArchiDroid's Backend Control and modify them, however keep in mind that every additional rule WILL slow down your network speed.
4. In default configuration local dns server uses two OpenDNS servers at port 5353, two Google DNS servers at port 53 and up to two local DNS servers provided by your Wi-Fi/3G connection, which overall gives a sum of 6 remote dns servers. In some rare scenarios (f.e. some wi-fi hotspots) you can notice that a moron, administrator of this wi-fi, blocked all dns queries and forces you to use his DNSes. This is BAD because of freedom and so on, but it's very common practice, that's why I turned on local DNSes as well. If you want to improve your privacy at least a bit, you can disable local DNS servers and then use only OpenDNS and Google DNS.
5. Above option initialy has been written to allow you one-time access to such non-trusty wi-fi's. But if you for any reason need automatic update of your local DNSes (3G and Wi-Fi's will use different local DNSes), you can also turn on Local DNSes Daemon, which will automatically query and update local DNSes if needed. This is also turned on in addition to local dnses above, of course in default preset.
ArchiDroid's Forced Update (RunOnce)
Forced update selected during mode selection in aroma tells RunOnce to work in "INSTALL" mode even on "UPDATE" mode, apart from that it works exactly the same as update mode, only RunOnce is affected.
Credits
First of all many thanks to JustArchi, who gave me the permission to port this rom
and helped me not only one time to get all things to work :good:!!!
Many many thanks JustArchi for the help and support!
ArchiDroid Core
- AROMA Installer
- AROMA Filemanager
- Boeffla Kernel-> @Hbohd plus his team not only because he was the first who ported and provided us a kernel for JB 4.3 and is doing it till today!!!
- Angi Kernel -> @psndna88
- PhilZ Touch Recovery
- SuperSU
- Nova Launcher
- TouchPal Keyboard
- Hacker's Keyboard
- Android Terminal Emulator
- BetterBatteryStats
- Cool Tool
- Greenify
- MX Player & Custom Codec
- LMT
- Root Browser
- Titanium Backup
- CrossBreeder
- Online Nandroid
- Xposed Framework
- App Settings
- XPrivacy
- Debian
- cURL
- GitHub
ArchiDroid 2.X
- OmniROM for GT-I9300
- Linaro Toolchain
- Spirit 2
- Wanam Xposed
ArchiDroid 1.X
- SamMobile
- JustArchi's Android Kitchen & dsixda's Android Kitchen
- Boeffla Kernel
- Yank555.lu Kernel
- KitKat Revolution Theme
- Blue Theme
- All Backs Black Theme
- Wanam Xposed
Special thanks to:
- Kenshin, for graphic design and ArchiDroid Touhou bootanimation
- @mrtur, for graphic design and helpful hand during ArchiDroid experimental tests
- @malachow, for helping users across both international and polish board, sharing the spirit of ArchiDroid
- All ArchiDroid Contributors, for improving and making ArchiDroid better!
- ArchiDroid Facebook Group, for beta-testing the very first alphas of ArchiDroid 2.0.0
- ROM Cleaner, for awesome generic list of bloatware
- Android Revolution HD, for being ex-ArchiDroid 1.X base
- WanamLite, for being ex-ArchiDroid 1.X base
- Temasek's Unofficial Build, for being ex-ArchiDroid 2.X base
- crDroid, for being ex-ArchiDroid 2.X base
- You, for choosing ArchiDroid over other available ROMs
So finally finished
looks good bro, keep up the good work :good:
Thanks...yes and high five ...fortunately today is public holiday here in germany I got some time !
Awesome, I tried porting using porting guide before but unfortunately it didn't boot compiling from source is probably the way to go, I guess. Thanks very much @rodman01 and @JustArchi!
ohh typo in thread under the xda Dev
his Rom is an official kanging of i9300 <---- link has extra h in the http
chongc1996 said:
Awesome, I tried porting using porting guide before but unfortunately it didn't boot compiling from source is probably the way to go, I guess. Thanks very much @rodman01 and @JustArchi!
Click to expand...
Click to collapse
yeah tried that too, unfortunatly didnt boot. now im trying to build from source with VirtualBox Ubuntu, of course getting help from some guys like my neighbor Rodman, great guy btw! :laugh:
Nice looking ROM
I ran this ROM on my S1, nice to see it on the S3LTE now.
Thanks
For me it's better to port Archis 1.X rather than 2.X. We are still lacking of stable roms on our devices.
Waiting for boot fix since it's not booting ATM.
Wysłane z mojego GT-I9305 za pomocą Tapatalk 2
Perhaps I will do the 1.X too, because I am interested in too. But nor sure when...
painball said:
For me it's better to port Archis 1.X rather than 2.X. We are still lacking of stable roms on our devices.
Waiting for boot fix since it's not booting ATM.
Wysłane z mojego GT-I9305 za pomocą Tapatalk 2
Click to expand...
Click to collapse
Not sure if it doesn't boot, it should boot, me and maho_66 were talking about our own attempts to port this. You should give it a shot!
Sent from my GT-I9305 using XDA Free mobile app
rodman01 said:
Perhaps I will do the 1.X too, because I am interested in too. But nor sure when...
Click to expand...
Click to collapse
Get in touch with my ArchiKitchen if you wish to make 1.X release.
http://forum.xda-developers.com/showthread.php?t=2597220
Basically:
1. You download any Samsung release in .tar.md5 format for Odin.
2. You extract from this .tar.md5 system.img boot.img (cache.img modem.bin - these are optional)
3. You load it with ArchiKitchen and you make deodexing, rooting, busyboxing, zipaligning and ArchiDroid init.d.
4. Then you create a ROM from AK and the effect should be similar to my base release: http://forum.xda-developers.com/galaxy-s3/general/rom-sammys-stock-deodexed-rooted-t2682453
5. You put in in the ADROOT and you run known magic build.sh script with "sammy" parameter - "bash build.sh sammy"
6. It should start extracting and replacing everything, as you know .
What is a difference with sammy and no sammy parameter?
- When building in sammy mode, build.sh doesn't compile anything and jumps straight to extracting .zip
- It also applies some sammy-related misc tweaks like ArchiDroid wallpaper, because this requires putting image in .png format in framework-res.apk
The fact that its not booting has i.m.h.o something to do with the correct/missing libs and or wrong permissions, for someone who is new to all of this its very frusturating i know, but you could give it a try whe sure need more stable roms i agree
Sent from my GT-I9305 using XDA Premium 4 mobile app
@rodman01
https://github.com/JustArchi/ArchiDroid/commit/14739db139ca50eedbfef5b26ac2933a24c70cf5
This should make you happier .
Make sure to check RunOnce Init and Cron logs after you merge upstream.
2.X works a great here.. Many customizations very smooth battery friendly.. Illl be sticking with this for the time being for sure.. Great work mate!
Sent from my GT-I9305 using XDA Premium 4 mobile app
The lockscreen notifications commit to omni hasn't been merged as of yet, I'll be watching until it gets merged
Sent from my GT-I9305
Performance wise this is definitely the best ROM out for the 9305 and I've tries them all.... Highly recommended !!
Sent from my GT-I9305 using XDA Premium 4 mobile app
Has anyone worked out a way to add different quick tiles?
Sent from my GT-I9305 using XDA Premium HD app
Well, this is just a simple script to view Nice Value/Niceness of processes and PIDs. I made this because i can't seem to find a simple and direct way to view niceness, so I'm sharing it with you.
Okay, What is Nice?
nice is a program found on Unix and Unix-like operating systems such as Linux. It directly maps to a kernel call of the same name. nice is used to invoke a utility or shell script with a particular priority, thus giving the process more or less CPU time than other processes. A niceness of −20 is the highest priority and 19 is the lowest priority. The default niceness for processes is inherited from its parent process and is usually 0.
Uses and effect
nice becomes useful when several processes are demanding more resources than the CPU can provide. In this state, a higher-priority process will get a larger chunk of the CPU time than a lower-priority process. Only the superuser (root) may set the niceness to a smaller (higher priority) value. On Linux it is possible to change /etc/security/limits.conf to allow other users or groups to set low nice values.
How to Install:
Download the pdf file linked below
This needs busybox so you gotta have one - tip: use @YashdSaraf's
Move it in '/system/bin' or '/system/xbin'
Rename to niceness (or anything you want)
Set permissions to 755
How to Use:
Open Terminal Emulator or adb shell
Code:
niceness (name of the running process/pid)
BOOM!
Download
https://www.androidfilehost.com/?fid=385035244224394124
reserved
same can be achieved with below command in terminal emulator -
busybox ps -o pid,nice,comm
JumboMan said:
same can be achieved with below command in terminal emulator -
busybox ps -o pid,nice,comm
Click to expand...
Click to collapse
i know, but I'm lazy to type all that stuff so I made it :silly:
Thanx, ll use it
Utility for background calibration, curation and tuning of the device towards an intuitive interface.
Subsystems being battery, entropy, encryption, disk, cpu, memory, filesystem, ui, scheduler, and network, all safe and open source technology.
Presented in this educational gaming metric format with infinite feedback and an interestingly assymetric chance. scribble anywhere, check in some stress, or find the 8!
waut.ch! does one hope to receive from this?
Well, increasing degrees and amounts of a certain "Je ne sais quoi" or responsiveness from the user interface for a start. Better battery life perhaps. Better quality of life, maybe.
And waut.ch! can only perhaps be described as "A qualified quantification of the placebo effect"
waut.ch! might benefit from this?
In the Android device space:
Designers
Users
Manufacturers
Recyclers
Developers
Compilers
Support personnel
OEMs
The Friendly Neighborhood Nerd/Technician.
“Make the most of yourself....for waut.ch! is all there is of you.” - Ralph Waldo Emerson ( paraphrase )
All along the waut.ch! tower - Bob Dylan
waut.ch! - Sometimes used in some colloquium as "watch!", keen upon reducing the TDP of mobile devices to 1.0 watt!
ARM variants of Android only Donut 1.6+
Please uninstall either Seeder or CrossBreeder prior to using this.
Root recommended, else reactivity metric is interesting and introduces uniqueness into the entropy pool anyway. Metric may demonstrate a certain asymmetry that is expected from predictable human actions. Efforts have been made to remove time seed logic from haveged in order to improve upon encryption and system-wide performance and security.
Also numerous other subsystems require careful calibration to facilitate this process.
Rewritten code, subset of functionality for upstream project - CrossBreeder ( https://forum.xda-developers.com/showthread.php?t=2113150 )
Please feel free to view and analyze source and functionality and report bugs and discuss etc on the XDA forum:
( https://forum.xda-developers.com/android/apps-games/app-waut-ch-calibration-android-t3549967 )
Google Play store:
( https://play.google.com/store/apps/details?id=ch.waut )
Please visit: /data/data/ch.waut/files/bin on the device itself for partial shell source code and XDA Downloads section and Github for full source code.
Reboot at convenience liberally or sparingly to reseed the entropy pool or as is known in common parlance, for good luck!
Thanks.
Havged source code:
https://github.com/Openand-I/haveged
Adhoc Payment URL to support development efforts : https://paypal.me/openand/10
Frappe ( "free-paid" ) same-version to support development efforts : http://waut.ch
Custom haveged source code as used in this piece of software: https://github.com/Openand-I/haveged
=====
Version Name: 59a6333e-9ed9-43f8-8dad-51ed46c17e28
cb.sh: cache pressure - 500
cb_io.sh: read_ahead - 0
cb_io.sh: nr_requests - 0
$ md5sum *.apk
661c30b02b2321300624af98feaa5bad *145-waut.ch.apk
661c30b02b2321300624af98feaa5bad *oi.apk
$ sha256sum *.apk
6d23b8da87dc5516583a55a3203c9f5068ea8fe8765ece489080ef663c8aee15 *145-waut.ch.apk
6d23b8da87dc5516583a55a3203c9f5068ea8fe8765ece489080ef663c8aee15 *oi.apk
https://github.com/Openand-I/haveged
https://github.com/openand-inc/waut.ch
https://forum.xda-developers.com/devdb/project/?id=19218#downloads
https://forum.xda-developers.com/android/general/app-waut-ch-calibration-android-version-t3858365
https://github.com/openand-inc/waut.ch/raw/cb0c60025f86a4fdc4778506e97ee80eb1c00b45/oi.apk
https://github.com/openand-inc/waut.ch/raw/master/145-waut.ch.apk
-------------------------
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
then simply run the app to initiate a time sync
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Note: Please note that the haveged binary in the APK is a static binary and works on both PIE and non-PIE environments. It is also UPX compressed. UPX for Android didn't compile. So UPX for linux was used to compress the executable file. It is an elegant solution as both on disk and in memory space(?) is reduced by 70% per executable. One is welcome to decompress the file using 'upx -d'.
Full source code is provided on Github and build scripts are attached here and on Github.
There is no license required to both install the app or distribute it, both within the developer ROM community or in commercial form. Adhoc payment URL to support development - https://www.paypal.me/openand/10
Again do note that the license to use the APP and source code is free worldwide and irrevocable in full or partial form. All other open source components simply inherit their license. But under no circumstances is any use thereof legally binding or relevant.
--------
Utility for background calibration, curation and tuning of the device towards an intuitive interface.
Subsystems being battery, entropy, encryption, disk, cpu, memory, filesystem, ui, scheduler, and network, all safe and open source technology.
Presented in this metric format with infinite feedback and an interestingly assymetric chance. scribble anywhere, check in some stress, or get lucky for that matter!
-----
ARM variants of Android only Donut 1.6+ ( should even be compatible with the latest ARM Android 9+ )
Please uninstall either Seeder or CrossBreeder prior to using this. And other "mods" or "tweaks".
Root recommended, else reactivity metric is interesting and introduces uniqueness into the entropy pool anyway. Metric may demonstrate a certain asymmetry that is expected from predictable human actions. Efforts have been made to remove time seed logic from haveged in order to improve upon encryption and system-wide performance and security.
Also numerous other subsystems require careful calibration to facilitate this process.
Rewritten code, subset of functionality for upstream project - CrossBreeder ( https://forum.xda-developers.com/showthread.php?t=2113150 )
Please feel free to view and analyze source and functionality and report bugs and discuss etc on the XDA forum:
( https://forum.xda-developers.com/android/apps-games/app-waut-ch-calibration-android-version-t3858365 )
Google Play store:
( https://play.google.com/store/apps/details?id=ch.waut )
Please visit: /data/data/ch.waut/files/bin on the device itself for partial shell source code and XDA Downloads section and Github for full source code.
The app will amongst other maintenance tasks tune sqlite databases regularly and reseed the entropy pool or as is known in common parlance, for good luck!
Thanks.
Payment URL: https://paypal.me/openand/10
XDAevDB Information
waut.ch!, App for all devices (see above for details)
Contributors
idcrisis
Source Code:
[url]https://github.com/Openand-I/haveged[/URL]
[url]https://github.com/openand-inc/waut.ch[/URL]
[url]https://forum.xda-developers.com/devdb/project/?id=19218#downloads[/URL]
Previous Version Information - 144
305bd30f-0c8a-40d8-baf5-330c68f62d51
Status: Stable
Created 2017-01-01
Last Updated 2020-08-18
$ md5sum *.apk
8ea8e8c132a584767a12e394f7975654 *144-waut.ch.apk
8ea8e8c132a584767a12e394f7975654 *oi.apk
$ sha256sum *.apk
4925066a106c83b18ac6e563f03331c56b72777e66973db591c9776d706595e3 *144-waut.ch.apk
4925066a106c83b18ac6e563f03331c56b72777e66973db591c9776d706595e3 *oi.apk
https://github.com/Openand-I/haveged
https://github.com/openand-inc/waut.ch
https://github.com/openand-inc/waut.ch/raw/master/144-waut.ch.apk
https://github.com/openand-inc/waut.ch/raw/f699d3763507ec1f91d82b9ce25c53036b460a9e/oi.apk
-----
Version notes:
haveged: static non upx binary used
cb.sh: lock fixes
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
then simply run the app to initiate a time sync
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Please support development, simply use https://paypal.me/openand/10 or the payment URL.
Or you can simply buy the "frappe" ( free-paid ) version of the app: http://waut.ch
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Issues:
- superuser - Please disable mount namespace separation in the superuser app ( for optional but recommended mount options ). Also please revisit the app entry inside the superuser app to ensure the waut.ch service can run on boot unattended. One can see the logs on another day to ensure that the scheduler ran correctly in the night.
- Non root users - User Interface can help in clearing the random device. Please try and obtain root to avail of most features
- Some Samsung users - One is also requested to raise a ticket with Samsung who may be running old PE detection rules that flag any compressed EXE.
- x64 users - Reports are that the binaries run on 64 bit as they are static! Please compile one's variant of the binary if required. Entropy generations removes CPU jitter and hence runs cooler and more secure.
- Intel users - User Interface can help in clearing the random device. Please compile one's variant of the binary if required. Entropy generations removes CPU jitter and hence runs cooler and more secure.
- Maintenance scheduler VACCUUMS and INDEXES "ALL" SQLITE databases. Some folks may not like that. But given that they're no WAL mode anyway, it's a bottleneck worth removing safely.
- There is a concerned effort to state that 32-bit ARM Android Go/One < 1 GB RAM devices are all that's required for long term functioning. Higher no issues.
- Please try and use a heap size of 96MB. Attempts have been made to set heap size dynamic but ideally this should be done in the build.
- Please clear cache or factory reset upon issues to gain at least another year of MTTR ( Mean Time To Recovery ) for each device.
Thank you!
License
License concerns:
haveged - inherited - https://github.com/Openand-I/haveged
busybox - inherited - https://github.com/openand-inc/busybox
- Busybox simple extract, possibly edit the .config file in 'vi' and type 'make'
The requisite tools are installed using:
apt-get install gcc-arm-linux-gnueabi
apt-get install libncurses5-dev
apt-get install gawk
The following is a step in another direction as the 'make' command works perfectly after extraction, but this is provided for posterity:
wget http://busybox.net/downloads/busybox-1.24.1.tar.bz2
tar -xjf busybox-1.24.1.tar.bz2
cd busybox-1.24.1/
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
At the menu, you can configure BusyBox options. Once configured, you can build BusyBox:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
sqlite3 - inherited - https://github.com/openand-inc/sqlite
waut.ch - 'none', non legally binding, and non legally relevant on a worldwide scale and irrevocable ( derived works are allowed to add their own licenses as long as the import ( meaning ) of the phrase "non legally binding and non legally relevant" is implied throughout ( not required to include text at all )) and does not reflect upon future updates of this software in any manner adversely.
He is back! Welcome back! Looking forward to this great new project! The only thing I might be missing is the dnsmasq filtering, which in my opinion if by far better solution than any kid of firewall/blocker
Sent from my Galaxy Tab 2 3G using Tapatalk
qWantUS said:
He is back! Welcome back! Looking forward to this great new project! The only thing I might be missing is the dnsmasq filtering, which in my opinion if by far better solution than any kid of firewall/blocker
Sent from my Galaxy Tab 2 3G using Tapatalk
Click to expand...
Click to collapse
Mate!
There are some serious issues with DNSMASQ.
- It crashes on wrong syntax of any option. Cannot do for a server.
- Command line syntax changes between original branch, Android and Cyanogen MOD. Not merged.
- Android fork far behind main branch
- Consumes port 53 on server run without sharing interfaces. This is on the Android branch. Main branch has this resolved.
- CPU loop for most Android DNS versions that show up only upon server run, rather than the tethering run. Possibly hijacked open source branch.
- Tethering modifications to Android branch ( command line addons ) not required any more as the main branch has incorporated methods to dynamically change IP addresses on the fly.
- It is probably encumbered by coding standards and export issues with only one developer. It is emblematic of most such over-reused projects.
- Hash table in memory, therefore future block list will use up RAM. Some others have disk based caching.
- Static blocklists are fairly not scalable for 10 years hence. Needs wildcard blocklists.
- DNS cache poisoning/overloading ( leading to denial of service) possible by any process/app.
It is therefore recommended to use either of:
pdnsd
unbound
djbdns
and standalone dhcp clients and servers from the Entware repository. And also these are interesting:
DANE
DNSSEC over TLS
BTW, all Android is encumbered by simple denial of service attack simply by reading from /dev/random by any app.
In order to try and package this into a simplish product, deleting /dev/random was not implemented.
idcrisis said:
Mate!
There are some serious issues with DNSMASQ.
- It crashes on wrong syntax of any option. Cannot do for a server.
- Command line syntax changes between original branch, Android and Cyanogen MOD. Not merged.
- Android fork far behind main branch
- Consumes port 53 on server run without sharing interfaces. This is on the Android branch. Main branch has this resolved.
- CPU loop for most Android DNS versions that show up only upon server run, rather than the tethering run. Possibly hijacked open source branch.
- Tethering modifications to Android branch ( command line addons ) not required any more as the main branch has incorporated methods to dynamically change IP addresses on the fly.
- It is probably encumbered by coding standards and export issues with only one developer. It is emblematic of most such over-reused projects.
- Hash table in memory, therefore future block list will use up RAM. Some others have disk based caching.
- Static blocklists are fairly not scalable for 10 years hence. Needs wildcard blocklists.
- DNS cache poisoning/overloading ( leading to denial of service) possible by any process/app.
It is therefore recommended to use either of:
pdnsd
unbound
djbdns
and standalone dhcp clients and servers from the Entware repository. And also these are interesting:
DANE
DNSSEC over TLS
BTW, all Android is encumbered by simple denial of service attack simply by reading from /dev/random by any app.
In order to try and package this into a simplish product, deleting /dev/random was not implemented.
Click to expand...
Click to collapse
Very comprehensive explanation indeed! I am no expert in Linux, only an average user [emoji6]
I was not aware of so many obstacles using dnasmasq, but aware of it's unreliability while using it for blocking stuff in pfsense. But I must say, I had similar experience with unbound, however, probably due to the lack of linux knowledge.
The way I understand is that host blocking is no longer viable due to scales of blocking required today. But sadly there is no alternative for that on android. I have been trying another tool, called sharkmasq but developer sadly abandoned it, while it seems very unfinished and unreliable. I also understand the reasons behind leaving netfiltering out of your development, just, in desperation, I search for the hope [emoji3]
P. S.
Thank you very much for your reply and for your time putting it together. Nevertheless I will look forward to further developments of this new exciting project!
Sent from my LG-D855 using Tapatalk
Uhm, my device seems more responsive even when I use a very low CPU frequency, but is it normal that the app doesn't ask for root permission even if I'm fully rooted? I'm using a Nexus 5 running Nougat. Thank you
Inviato dal mio Nexus 5 con Tapatalk 2
Hi, yes, part of the design criteria. Without root, the metric is interesting. With root, it will automatically start the background processes including the daily cleanups.
Best way to know that the background processes are running is to install Seeder ( but whatever you do don't start it! . Entropy should show around 4096.
Still in the testing phase, does it worth excluding the app from "android optimisation list"? I also use "power nap", not sure will that cause any side effects...
Sent from my LG-D855 using Tapatalk
Let us know If Seeder has RNGD off and still reports ~ 4096 entropy then all is hunky dory.
The new update asked me for root permission, all right here now
Have been busy lately with life, but had occasionally played with phone. So my findings so far: I use this app on my old galaxy tab 2 3g on slim6. Seeder shows entropy being filled in no time at all. Can't really say much about performance, but it seems that it behaves a little smoother. I also use it on my daily LG G3 on stock MM rom with custom kernel, but seeder is reporting very low entropy, if seeded is left on for 1 minute, I can see that entropy never goes above 900? Goes up slowly but then gets used, and then very slowly goes up again and gets used.
Sent from my LG-D855 using Tapatalk
Reboot once after first install kicks in the animation changes. And good luck
New version uploaded with haveged updates. Build scripts also added.
Feedback solicited about the compiler flags etc. Basically the idea is that the ARM v5 binaries should work for all past and future versions of 32-bit Android without modification.
UPX binary could only be compiled for x86 linux.
To answer question, second device, not running, may need to check su logs
Also backend binaries are 32 bit, may not work on 64 bit. GUI's ok.
I am very confused about the frontend of this app that looks like some number game that I really don't understand . Also, I don't understand the description very well. Finding the 8??? Reboot when animation kicks in? What animation?? Nothing seems to happen. I just see a still of a beach with a red number
But something DID happen though, so I am in business. I will keep you curious for a moment, while firstly giving you a good reason for a hard laugh:
I am trying to revive an LG L3 E400! Yep, that's right . Just for fun and educion. In fact I already succeeded quite a bit. I flashed JellyCast V7rev1, used some stuff from V6 SuperCharger (not entropy thingie coz I already intended to use CrossBreeder for that) and 3 scripts from Fly-On Mod. I came here via the CrossBreeder thread (of course). I have already tried CrossBreeder 7.2.13 (I followed advise from @f3tus here, he advised to use that older version). Entropy went up (so it worked) but I did not experience much performance improvement. I did experience more "not responding" issues though. So I reverted to the pre-CrossBreeder backup. And then came your app.....
So that's a very short summary of the many, many, many hours I spent last 2 weeks on this ancient minimalistic but very adorable phone. Now... back to this Waut.ch! app. Presuming that it had done something, I checked the entropy level after first reboot: still a jumpy number between 150 and 200 or so. Despite the fact that the service shows up as running. Then, a lot more playing with the "game" without understanding what I was doing. Just hoping for some wonder. Some message.... just...... something! But nothing. Just a beach with a red number. And a clock. And a questionmark. Or exclamation mark. Pffffff.. So.... let's reboot again. Then eat a sandwich and drink (more) coffee. Then check entropy again. And there it is! Steady at 4089! At first I thought his app was failing because the number didn't change anymore. Just steady. With the old CrossBreeder 7.2.13 I got 4096 a lot but it was a very jumpy number, going even below 1000 a lot. Well, some time passed while writing this post so let's check again: Wow, right now it says 4091 (99%)! One hour later: 4092! (It had spontaneous reboots inbetween).
I am testing it now for a few hours and have these problems:
"Not responding" issues (same as old CrossBreeder).
Spontaneous reboots (3 already). One of them failing to boot at all (stuck at JellyCast logo).
Two times, after a reboot, GPS was disabled. Not consistently though.
No noticable performance gain.
By the way, I am testing like real world usage. Just opening, using and closing apps. I use the same apps all the time so that gives a very good feeling about performance. More meaningful than benchmarks to me. My goal is to make this phone suitable for normal daily usage.
Your app is using a combination of serveral mods, right? I would like to be able to enable / disable each one separately. How can I do that? For example, I have a gut feeling that my "not responding" issues (and reboots?) do not come from the entropy mod but perhaps from governor tweaks or something else. Any chance that you will add enable buttons in the app? Or supply seperate scripts?
Update: I DO have performance gain! Not consitently though. Apps sometimes starting faster than ever. Also still the aforementioned quirks. Last hours no more auto-reboots. Entropy reaching 4096 now, just a little bit wobbly. There seems to be a lot of potential.
The stutter was an issue with the last version.
Do try the latest one and let us know.
Also better if you install the Play store also so the updates are automatic.
Version name is changed GUID if comparing. Better than comparing version numbers.
GUI is non functional, just a visual representation of haptic feedback and actual randomness spread.
It's like drawing points in the whites of a poached egg. If you can see a pattern, you'll be rich in the stock market
Today I removed the app. The biggest problem is random reboots for me. As said, it has potential because sometimes apps started faster than ever on my ancient LG L3. But not consistently. So maybe I 'll try again later.
Sorry for my first post, probably tl;dr. I will repeat my most important question: can you provide us with separate scripts? I mean: I would like to test the entropy thing without the other tweaks as you described in the OP.
Dude!
You're probably using an old version. We'll never know. Will we? Will we now?
There's a small trick that borders on superstition. The famous random device block gremlin tends to disappear if you run the GUI in scribble mode. Basically what may be happening is the block is hit and then the stupid kernel makes whatever decision it makes. Usually at the cost of usability in favour of some stupid religious Linux fervour. Someone should report that to LINUX.
Or another entropy generator, haveged or RNGD or Seeder may be running. Which is a big no! Best to run it on stock ROMS or full custom ROMs ( please ask the developer if they're running any variant of above and to recommend coexistence or better variant of any subcomponents or piece of code. ). In other words, open source!
Also, the separate scripts are in the /bin directory on the phone itself. May require bash and ADB skills.
And full source on XDA and GitHub.
I'll construe this as a possible request to also post the shell scripts from GitHub into the XDA project as separate attachments. Which I can do. In due course
Cheers.
Well, I took it from Play Store. Is that an old version?
Jump To:
Linux vs. Android: LINUX BE POSSIBLY INSTALLED ON ANDROID DEVICES?
Possible Methods of Android-Linux Dual Booting: CHROOT vs. LXC vs. VM
[Q] I download setup (an ISO) of Windows or Ubuntu from internet and install it on my laptop. The same ISO is booted and installed on my office PC and on my friend's PC. Then why can't I download Windows or iOS or Linux for mobile and install it on my mobile phone and my brother's?
[Q] Why I can't install the Android OS designed for my phone on my friend's phone? Both have same architecture (ARM) and same SoC vendor (Qualcomm) and same hardware vendor / OEM (say Samsung).
[Q] Why I have to download a firmware/ROM specific for my device?
[Q] Why a generic/regular Android OS installer is not available for all Android devices?
Let me try to understand it and explain it.
For an OS to work on a hardware, two conditions must be met:
Software (OS) developers and hardware vendors/manufacturers willing to work with each other.
This is something purely related to business.
Software (OS) and hardware willing to work with each other (compatibility).
This can be due to first point i.e. commercial constraints or due to technical limitations of one for other. We can classify this incompatibility in further classes:
Difference of architecture
Difference of hardware other than CPU and hence of drivers required
Difference of booting process. It's also hardware related
ARCHITECTURE
Machines are to facilitate human beings. To interact with devices (digital machines), we need to talk to them in their machine language; the language of yes and no (0 and 1). They don't understand English. We (the laymen) don't understand zero's and one's. Operating systems solve this communication barrier by going through multiple layers of translating, interpreting , (de)compiling and (dis)assembling different languages between us and metal/silicon hardware. Human language is translated to some high-level language like C++, easily understood by human. Then it's translated to some low-level language like Assembly, easily understood by machine.
But as all humans don't understand same language, machines don't either. That's what define architecture. Since receiving and forwarding instructions is the responsibility of CPU, architecture is associated with CPU. Different CPU's understand different set of instructions like x86, arm, powerpc etc. Also there's difference how many number of instructions a CPU can process at a time i.e. 32-bit, 64-bit etc. While translating (compiling) a program from high level language to low level language, architecture is the primary concern. A program/binary/library compiled for one arch can't run on other and thus every OS (which is a set of programs/binaries/libraries) is not able to work with every arch. CPU architecture and the instruction set it uses form an ABI which decides the format of executable binaries, such as programs and shared libraries.
OPERATING SYSTEMS
Broadly speaking, there are three flavors of OS's available to this day:
Windows
Most commonly used on home and office PC's and is proprietary i.e. we can't use it on any device according to our will unless the lord; Microsoft designs Windows for our device. They have very close ties with hardware vendors for better integration and compatibility with software.
Mac/iOS
Even hardware is proprietary and we can't use it on any device unless Apple does or permits to do so.
Closed Source
They both charge you a handsome amount for their software and/or hardware products providing a relatively stable solution but with very less flexibility for any further addition/subtraction. They don't want you know what's going on at back end, just enjoy what user interface offers and you may ask them if any support required. That's why they keep their source code (which is the translation between machine and human) closed because they invest in it. But to simplify our daily life tasks, we have a vast range of commercialized applications, software and utilities, available at a cost (or pirated; the other way ) that run on these proprietary platforms, Microsoft being on the leading edge due to it's easy availability and compatibility with large range of hardware. Thus, from a common user's perspective who doesn't want to indulge in technicalities, both of these are good options.
Linux (most common of the Unix-like OS's) maintained by GNU and FSF
Open-source and free and anyone can mold it to use in any device; a baby toy, a video game console, a music player, a monitor, a small network router, a TV or a server hosting a full website and even more.
Another thing we need to understand is,
PC (and Laptops etc.) vs MOBILE (and tablets etc.)
1. PC STANDARDIZATION
There is no concept of standardization for hardware in mobile world. And no one wants either. Every vendor devises it's own way to initialize the hardware, unique and signed bootloader, non-persistent methods to enumerate devices (often hardcoded and provided by a Device Tree Blob), and devices grouped / linked in ungraspable combinations etc.
PC's are standard (so far; thanks to efforts made by IBM in past). You can buy a motherboard and compatible CPU, graphics card, sound card, network card and hard drive, all from different manufacturers and make a PC yourself (though the concept is becoming obsolete and out of the box approach is preferred). Linux and Windows will run on that PC. However, Mac won't. It's because both parties (software and hardware) GNU or Microsoft and hardware manufacturers (Intel, Dell, HP whatever) follow those standard PC specifications. Mac doesn't follow because Apple wants just to run MacOS on hardware supplied by themselves (thought there's Hackintosh now). That's why Mac means a complete unit (OS and hardware), not just an OS on DVD like Windows. There is no "Windows Book" like "Mac Book". There's Surface Pro but Windows is easily available for PC's.
This is different in mobile phone scenario. There is "Windows Phone" like "iPhone". Both are tied to hardware. Due to the closed source nature of iOS and Windows Mobile, you can't even think of using them on a device other than provided by Apple or Microsoft. There are technical restrictions you can't cross and then legal aspects. They themselves own hardware and OS both but situation is slightly different in case of Android.
2. ANDROID ISN'T OPEN SOURCE
Android, like Linux, being open source can be used on any device but only if you can make them work on your device. In fact Android isn't open-source, AOSP is. If you go through the process of baking (or making) a new OS (i.e. ROM) for your device, you will come across device specific DTB, kernel and proprietary blobs / HAL's (hardware specific files). AOSP doesn't provide hardware drivers, those are OEM's intellectual property and are specific to the device hardware and AOSP version as well. So, Android for ABC device can't run on XYZ device. Project Treble is a recent attempt by Google to address this issue. Though it's primary goal is to enable hardware vendors to release more frequent AOSP updates for old devices without touching their hardware specific code but this project will enable ROM developers to easily port ROM's from one device to other since the HAL's / drivers won't be necessarily modified.
Google develops a "look but don't touch" type of open-source core OS "AOSP" (not considering hardware aspects) and hands over to device OEM's. They earn indirectly by binding OEM's in "Open Handset Alliance". By signing licenses with OEM's on strict terms and conditions for Google Play Services and apps, users are made captive of Google Services; the biggest app store, search engine, cloud storage, maps, YouTube etc. and selling ads through them. Any vendor trying to replace Google's closed-source products with their own alternates is rejected in Compatibility Test, hence unable to use Google's ecosystem i.e. no more Play Store. What a user will do of such a phone with apps store? You will be seeing gradual replacement of open-source AOSP Browser, Email, Gallery with closed-source Chrome, Gmail, Google Photos. List is long with Google Dialer, Contacts, Calendar, Keyboard, Messenger, Play Music and so on. May be one day AOSP will be fully closed-source. Na?
But for the time being, once the OEM's have AOSP source code, they mold AOSP to their needs not following any hardware standards (as in PC's) and feed it to their hardware (with closed source drivers). So here OS (AOSP) isn't proprietary but drivers are. Both components become essential for each other. Hardware can't run others' software and software can't run on other's hardware. You are left with no option other than using their "product". OEM's i.e. device manufacturers make changes to OS i.e. kernel and onward: DTB, initramfs, hardware interfaces, drivers for audio, RIL, GPS, Wi-Fi, bluetooth, camera, graphics and subsequently UI and apps. Some OEM's release kernel sources sooner or later as they are bound to due to GPL, but mostly (white-labelers) don't.
Prior to kernel in booting process, there are SoC vendors who embed their own peripherals on SoC's as well as from third parties to make things complicated. At very core low level, BootROM / IBL / PBL (bootloaders) which are hard-coded on SoC/CPU are signed to load only signed SBL (secondary bootloader) which loads only signed aboot (application bootloader) which loads only signed kernel (if not unlocked). Where this chain of trust protects users' privacy, it protects SOC vendor's benefits as well. You can't replace bootloader to adapt the boot process for some other OS. All the bootloaders and multiple partitions to assist bootloaders contain proprietary contents, leaving you with least chance of customization.
"Replicant", an FSF project (the same group behind free Linux), is trying to replace proprietry parts of Android with free open-source drivers. But it's very hard to reverse engineer proprietary components and maintain Replicant OS for every device.
3. TECHNICAL LIMITS
Coming back to the technical aspects, PC's have a standard BIOS/UEFI on motherboard which can configure boot options and can boot from many bootable devices like USB or CD/DVD. So we can start installation of OS with a bare BIOS on PC which happily interacts with bootloader, whether of Windows or of Linux. OS have hardware support i.e. drivers from all possible manufacturers included in OS which are loaded and installed accordingly during installation process. Mobile devices are designed with lesser hardware resources and limited functionality. To make a mobile device multi OS supported, there come storage space and device compactness constraints and connectivity options thus installation media issues. There's no BIOS in mobile phones. You can't simply boot from a USB or optical drive and hence there's no installation of OS possible. Installation is somewhat irrelevant term for mobiles devices. Here, partitions are "flashed" i.e. ready-made material is extracted to them.
There have been successful attempts booting Android from USB / UART ports and before that using engineering SPL's when chain of trust inside SoC wasn't that tighter and it was possible to load IBL without integrity check. But it's impossible for most of Android and other phones due to electronically signed bootloaders. Read ANDROID BOOT PROCESS for further explanation.
PC's have hard drives which can be partitioned and re-partitioned. If something goes wrong, BIOS is there to handle booting part. You can put inside an old HDD living in your scrap box to boot your PC. PC OS's are bundled with utilities to handle this "partitioning" part automatically. And in most cases OS is installed on a single or two partitions. Mobile phones have eMMC's (flash media soldered to boards) which may have up to 50 partitions on it. And you can't think of playing with these partitions unless you are willing to buy a new phone which is the case when something goes wrong with partitions due to eMMC's completed number of read/write cycles after a year or two. You can hardly re-partition it. Addresses of partitions are hard-coded in SoC from where to load what. With a damaged bootloader partition, phone doesn't know what to do when you press its power button. There's a high probability that you will lose access to even Emergency Download Mode, which is the last resort. The same goes true when other parts are malfunctioning. Considering the cost of repair and replacement (if possible and available), you would definitely opt to replace whole phone.
CONCLUSION
In this scenario of so much hardware ambiguity and diversity, with "M" number of mobile phone models released today and with "O" number of operating systems available to till date, who and why will make "M x O" numbers of ports everyday so that users can enjoy the flexibility of desired hardware and software like on PC's?
What Linus Torvalds has to say about this scenario when comparing the silicon valley king of PC world; Intel (x86) and the major SoC vendor of Android phones; Qualcomm (ARM):
"I've been personally pretty disappointed in ARM. Not as an instruction set, although I've had my issues there, but as a hardware platform it's still not very pleasant to deal with... It doesn't have the same kind of unified models around the instruction set that we have in the PC space."
Click to expand...
Click to collapse
So from above discussion, answer to "Can Windows/iOS be installed on Android phone?" is NO. At least not simply. First technical reason is, it's harder. Microsoft's support for ARM architecture is only a few days old while Apple uses a custom-designed ARM version. They don't work on Android ARM devices. And even if they do, they don't work with other hardware included in Android devices. And even if they do, Windows/iOS is developed by one company: Microsoft/Apple. Android (not AOSP) is developed by every OEM (Samsung, HTC, Xiaomi, Huawei, Google, Nokia, OnePlus, LG, Motorola bla bla bla). How can Microsoft/Apple develop an individual version of Windows/iOS for every model of all these Android OEM's? Why Microsoft will engage their engineers to develop drivers for Samsung/HTC/Xiaomi phone? And why would Apple invest in making MacOS for Surface Pro? It's not justified, both, technically and commercially. Gadgets are low budget devices and users tend to change them now and then unlike PC's which are supposed to be used over years and years.
COMMERCIAL ASPECT
Second simple reason is, it's business. In mobile phones everything is proprietary; hardware and software, whether it's Windows or iOS or Android. If there's no commercialization and proprietorship, who will invest and bring improvements at such a high rate? If you use my software, why not my hardware? And vice versa. Making money by providing services and products isn't an ignore-able option in this materialistic world rather than running a sponsors' funded Free Software Foundation.
. . . continued . . .
LINUX vs. ANDROID
. . . continued . . .
LINUX BE POSSIBLY INSTALLED ON ANDROID DEVICES?It's both: YES AND NO.
Though there is no (or negligible) proprietorship in Linux, there are technical obstructions as discussed above which make it difficult to install Linux on Android device. "Ubuntu for Android" is a stance of such failed attempt. It made use of Linux Containers (LXC) to run Linux with Android kernel. Ubuntu did their homework but abandoned due to no support from Android side. "Ubuntu Touch" and "Ubuntu Phone" are subsequent projects, almost abandoned. But there is somewhat proprietorship involved i.e. dependence on closed-source drivers.
And there is SHR.
Lets have a look at Linux vs Android to know why and why not:
Linux for ARM
Due to its open-source nature, many Linux distributions are available for ARM architecture. ArchLinux ARM port is available mainly for mini single board computers and tablets. Ubuntu ports are available for arm/arm64 as well as officially available for servers. Fedora supports desktops, laptops and workstations as well. Debian supports development boards, network storage and QEMU (virtual machine / hardware emulator) too. There are many others as well, mostly in development or trial phases.
Booting process of Android and Linux resembles up to some degree. Linux mainly focuses on PC-like systems or specially customized embedded solutions. PC's have a standard BIOS/UEFI to take control after power on unlike Android devices as discussed above in "PC vs Mobile" section. Android devices, being mobile phones / tablets, don't have any analogous of BIOS.
Since there is no BIOS/UEFI, there is no standard ACPI (power management) on Android; apps use wake locks for ON state, otherwise device is sleeping.
Android uses ARM devices mostly with SoC's manufactured by Qualcomm, which have very least support for mainline Linux kernel contrary to other silicon vendors like Allwinner and Atmel etc.
Read ANDROID BOOT PROCESS for further explanation.
Bootloader
Most commonly used bootloader in Linux is GRUB which comes bundled with OS and often resides with OS on the same partition. It's open source and you can even configure it. Android's most common used bootloader is aboot (or its derivative like hboot) which is closed source and signed by Qualcomm (SoC vendor) and it lives on a separate partition with it's suppportive components residing on multiple other partitions. It's to secure the device from booting any other bootloader, again for commercial purposes or to protect user's privacy. Also aboot comes locked and can't boot unsigned kernel images other than officially provided by OEM. However, in most cases, it's unlockable. Thus, Linux bootloader can't replace Android's bootloader. There's u-boot, the traditional embedded Linux bootloader but that too is helpless here coming to the "signed" part.
Kernel
Kernel being the core of OS, manages all hardware resources particularly memory and CPU. It uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion of many tasks being executed simultaneously.
We have an agreement on this part. Android kernel is inherited from Linux and both are open source (at least by GPL T&C) and similar enough. Though again Android kernel lives on an independent partition named "boot", similar to partition or directory "/boot" on Linux which also contains grub. But the differences in implementation of kernel are enough for incompatibility and the reason is non-standard nature of Android devices. Linux kernel is designed for standard PC's and include drivers (or at least drivers support) for almost all hardware vendors as does Windows. On the other hand, Android kernel, as explained above, is different for every device because every vendor includes its own hardware drivers which are not open source. Practically it's impossible to develop a universal Linux kernel of a few hundred MB's that works with such a diverse range of mobile phones.
In summary, we can run Linux on Android device if:
Android kernel provides all functionality of a Linux kernel (specifically compatible with glibc)
This condition is impossible to meet. Neither we can modify Android kernel to meet all needs of Linux glibc, neither we can modify userspace libraries to be compatible with Android kernel. Later will cut down many standard functions of Linux.
Or we have a fully working Linux kernel for the device (specifically drivers)
Compiling Linux kernel for Android is possible but the proprietary part (drivers) is almost impossible.
However, one may try to compile Linux kernel (native booting) for a specific Android device:
Get:
Android kernel source code
Firmware blobs / source from Android
Kernel modules from Linux (matching with kernel source version)
Compile Linux kernel (/boot/zImage and /boot/System.map-*) and initramfs (/boot/initrd.img.gz)
Let's say we are going to install Linux on second partition of SD card. Unpack Android boot.img and repack with Linux kernel, Linux initramfs, Android kernel base and cmdline something like "root=/dev/mmcblk1p2 console=tty0". Or pass root argument to bootloader while testing with fastboot:
Code:
fastboot -c "root=/dev/mmcblk1p2 rootwait" boot boot.img
"rdinit=" or "init=" might also need to be specified in cmdline.
"Framebuffer Console Support" and "Virtual Terminal Support" need to be enabled while compiling Linux kernel to enable "console=tty0" which is disabled by default on Android kernel.
But it's not very simple to achieve because all above requirements are rarely met. Getting all hardware work aside, a lot of kernel patches would be needed to hardly boot the device. Simple is to make some compromise and share Android kernel to start up a basic Linux environment.
Init (Startup service manager), sysV/systemD vs Android init
Init, being the very first process (PID 1) started by kernel, has very deep integration with kernel design. Linux traditionally has (almost had) sysV, then came, for a while, Upstart (by Ubuntu) and a few others, and now systemD (by RedHat) is most accepted service manager. Android init is derived from sysV init but it has additional responsibilities of ueventd (analogous of udev in Linux) and watchdog. It's open source and creates somewhat similar filesystems as those are on Linux. Services started by Android init are totally different than started on Linux. So, we cannot use Android init to start standard Linux services. But we can start a few of them (non-systemD, only from legacy paths /etc/init.d and /etc/rc[N].d, or direct execute binary) manually as daemons, once we have a basic Linux environment sharing Android kernel. However, init and particularly systemD starts services at boot in a defined order with entangled chain of dependencies on other services going up to kernel. Therefore, altering init's behavior (changing code and recompiling shared libraries blobs) is equal to writing a new OS.
Android init creates only one root filesystems from initramfs in which all other filesystem are mounted. While on Linux, usually rootfs created by initramfs is just for loading drivers etc. and it's subsequntly replaced by a persistent storage (partition) rootfs.
Linux init provides a platform to add or remove init services when new packages are installed or removed, by adding simple shell scripts to /etc/init.d on sysV or .service files to /etc/systemd.
But Android init has no such flexibility and it starts a fixed set of services at start, defined when ROM was made. Init configuration files found in initramfs/init*.rc and in /system/etc/*.rc or /vendor/etc/*.rc are meant to be used by vendors or ROM developers and not at user level. Though we can add a custom init .rc file, on Linux any user or package can modify and update initramfs at any time. We can add startup scripts to "/etc/init.d" on some rooted Android devices or custom ROMs which have init.d support enabled by modifying initramfs in boot.img. To start custom services/processes on boot, SELinux policy also needs to be modified such as daemon-su does.
Some other tasks which aren't part of init implementation on Linux, are handled by Android's init, such as configuring kernel parameters at boot. Android does not support /etc/sysctl.conf, so the updates to the /proc/sys/ are part of the "init.rc" file.
On a Linux system init along with scripts, binaries kernel drivers and modules (in initrd.img), kernel (vmlinuz executable) and bootloader configuration along with modules, they all reside on root or a separate partition (mounted) at /boot. While on Android, init along with a few binaries and configuration files and kernel reside in a separate partition named "boot" with a special filesystem.
A simple comparison of Ubuntu 16.04 (systemD) and Android 8.1 processes is given here.
Filesystems and Directories
As long as kernel part is concerned, /sys, /proc and /dev filesystems are same on Linux and Android with negligible differences. Both depend on a single root "/" filesystem. But other filesystems related to runtime environment and userspace differ i.e. /bin vs /system/bin, /home vs /data/media, /var, /usr, /media etc. But we can make use of resemblance in kernel and its filesystems to run Linux on Android device, not independently, but depending on Android OS for hardware handling.
A comparison of Android and Ubuntu is given here.
Virtual Terminals and Consoles
Linux kernel supports a native console and muxes multiple virtual consoles and terminals (accessible through Fn+F[N] keys) which are a primary method for user logins. Android uses modified Linux kernel, with only one /dev/tty which is the current terminal and the controlling terminal of any running process requiring a terminal. Like many eLinux systems, kernel console is either disabled on Android by default or not connected to any device and it's not muxing any virtual terminals because no text mode user login is intended and only GUI mode is used. However, support for both Virtual Terminal and Console in frambuffer mode can be enabled while compiling kernel.
For more details, have a look here.
Runtime Environment (Standard C library and Linker)
Let's think in another direction. Due to above said differences between Linux and Android, why don't we skip the installation part and run a complete Linux environment inside Android when it's completely booted? We can't.
As said at the start of this post, OS is a set of binaries/libraries compiled for a target OS and placed at specific paths to get maximum performance. These binaries/libraries execute in a certain order to perform required operations. For maximum utilization of hardware resources (i.e. to save space and minimize processing time), each program/biary/library isn't compiled independently (i.e. statically). In most cases, they are linked and dependent on each other (dynamically linked). A "linker" program (which is itself an OS specific static binary) links these binaries and libraries when they need to run. Dynamic linking makes executable files smaller and saves disk space, because one copy of a library can be shared between multiple programs.
Static linking is performed at build time by linker after compilation of libraries / binaries. If all required functions are statically linked to a library / binary, it doesn't need any support from OS at runtime, with a few exceptions. It's loaded in RAM as a standalone program just needing syscalls to kernel. However, in order to facilitate developers updating code and to save storage as well, static linking is not desirable in most cases. If we compile every application as a whole package, we'll be including same code hundred of times in many applications. Instead shared/dynamic libraries are referenced (using symbols, pointers) in program code at compile time but not included in executable. These symbols are resolved by linker i.e. libraries are searched recursively (searching libraries needed by already loaded libraries and so on) and linked to the program by creating addresses/offsets table in RAM before the program is executed. So the required libraries are loaded directly in RAM at runtime instead of linking in an archive file (static library) or binary (executable program) at compile time.
For dynamic linking, linker location is hard-coded in program (binary) code i.e. absolute path is set (can be specified by "--dynamic-loader" at compile time). Shared libraries are rarely hard-coded, instead those are searched in LD_PRELOAD, LD_LIBRARY_PATH, DT_RUNPATH directories, linker cache file or default directories.
Dynamic linking is often, but not always, accompanied by Dynamic Loading. It's the responsibility of program to load the required library when needed (not always at the start of process). Such programs (compiled with "-ldl" option) use dlopen syscall through libdl.so library for loading mechanism. In static loading, all libraries are loaded in RAM before execution of program starts.
Libraries are implemented through library files (lib*.so) and header files (.h). Header files (used at compile time) include function names while actual functions are defined in .c files. After adding the header file in a program code, functions provided by that library can be called instead of making syscalls to kernel.
One most important of these libraries is "libc" (Standard C Library) which is responsible for very core functions like memory management and input/output processing etc. Almost every single click or tap of yours on screen goes through the traditional libc API. libc provides very basic communication with kernel (through syscalls), acting as a bridge between kernel and userspace, so must be compatible with kernel (to make kernel understand syscalls).
C is the choice of many OS's because it's small in size, speedy and more human firendly as compared to other languages for low level programming. Libc is the most frquently linked library, almost every programs links to it for interaction with kernel. So, linker is implemented as a part of libc. Dynamically linked programs make use of std C API (header + .so files) while statically linked programs and kernel work independent of libc.
Similarly programs can make use of C++ Standard library which itself make use of all C header files (around 30 in no.) and a few additional. libz is also one of most excessively linked libraries.
Android and Linux have a different linkers implementation (/system/bin/linker and /lib/ld-linux.so respectively) and a different libc (/system/lib/libc.so and /lib/libc.so respectively).
Android owns a minimal set of Bionic (what Google calls it) libc while mainstream Linux uses glibc (GNU Library C) for its applications. They can't replace each other due to difference in functions they can perform and the locations too (filesystem hierarchy) where they reside along with other binaries/libraries. As mentioned in Filesystems, Android's major binaries and libararies reside in /system/bin, /system/vendor and /system/lib while that of Linux live in /bin, /usr/bin, /lib and /usr/bin. Therefore their linkers are compiled to look in these locations accordingly for the required libraries to link. But the main difference is in their capabilities.
Bionic is a trimmed+modified version of glibc and OpenBSD/FreeBSD C library, small in size and providing a different set of functions than glibc, just enough to get Dalvik working. Bionic was designed keeping in view the space limits, slower CPU's, bloated glibc and open-source license issues. It implements libc, libm (math.h), libdl (dynamic loader) and libpthread (CPU/RAM management for running processes). Android linker has also been designed in accordance with C library, not only different in name and location but also links libraries of different format.
Due to differences in libc and linker, dynamic binaries/libraries compiled for Linux won't always run on Android even if the architecture is same. Static libraries which have all functions (from different libraries) built-in and work independently of dynamic linker, even those have some dependencies on shared libraries at runtime. For instance, functions like dlopen (libdl.so), related to locales and Name Services (getuid, getpwent, getpwnam, getservent, getaddrinfo etc.) require at runtime the shared libraries (such as libnss_compat.so and libnss_files.so etc.) from the same glibc version used at the time of static linking, because paths are hard coded.
Some other differences:
User/group management on Android is different than Linux Name Services (NSS, NSCD, /etc/passwd, /etc/group. . .). Programs like whoami and id, if compiled on Linux, don't work on Android for the same reason.
Android's login process is quite different than on Linux. Bionic doesn't provide glibc's standard utmp/wtmp functionality. But same do other Linux libc's such as musl libc.
Locales (Native Language Support) are not supported by Bionic at all, glibc implements locale through gconv modules
No wide characters support (no iconv.h, use only Unicode in coding)
Limited libpthread (POSIX incompatibility) and libm functionality
Not using Linux syslog, instead uses __libc_android_log_print. /dev/log interface is also no more used on Android.
Domain Name Resolver (DNS) doesn't support Linux Name Service Swith (NSS)
No SysV IPC (managing data sharing between apps)
Bionic additionally provides a large number of System Properties through interface (/dev/__properties__/) using init's property service.
Unlike glibc, Bionic doesn't support C++ fully because it wasn't needed for Dalvik (Java). Android uses llvm libc++ (previuosly using libgnustl/libstdc++ and libstlport) to compensate this shortcoming for programmers. libandroid_support is a bridge to make libc++ compatible with Bionic.
For apps part, Android uses Java instead of native languages (C / C++ etc.). Dalvik VM is a kind of emulator running on top of native libc (and other libraries) to translate Java bytecodes into ARM understandable (native) code. This is how Java works; "write once, run anywhere" (WORA).
Root User and Linux Capabilities
Display Server and Display Manager
While binaries/libraries work at back end, a GUI (graphical user interface) is to facilitate the user at front end i.e. just click on a good looking button and OS will handle the execution of commands at back end, providing you with the required results. It frees the user from the trouble of remembering commands and their syntax.
Linux being developed for PC's comes with a desktop environment backed by a windows server (display server) like most popular X server and Wayland. Display server (protocol) is directly talking to kernel through input and graphics drivers as explained in next section. On the client side, display server is accompanied by a session manager which handles user login/logout, a desktop manager which draws a desktop and a window manager which draws and moves windows on screen. Additionally there can be panels, launchers etc. in a typical desktop environment. It consists of a few hundred packages, like main utilities being settings manager, file manager, power manager, network manager etc. Sound isn't a part of X server and is implemented separately.
Android's display server is SurfaceFlinger which draws surfaces (windows) in a quite different manner than Linux. It offers Java based apps. A launcher is an app equivalent to Desktop, a minimal UI to manage installed apps. File manager and settings are too separate apps. So the differences here too are large. Android's windowing system is totally different than that of Linux. "Mir", an amalgam of X, Wayland and Android, was a proposed display server for Ubuntu but the project is almost dead like "Ubuntu Phone". Wayland is closer to Android, a new project not designed for remote access, eliminating unnecessary parts of X windowing system. It's a compositor consisting of server and window manager as a single unit. It doesn't include input handling either, but implemented through "libinput" separately. However, the differences are large.
Display server and Display manager (login manager) are directly associated to Linux console and virtual terminals. Linux init lands us on a login manager or a fully working virtual console where we can use network related services, install packages, start X server, launch DE/GUI apps etc. Android has almost no concept of using kernel consoles or virtual terminals as discussed above. This is also a major difference limiting the use of display managers and servers on Android.
To conclude, we can't run Linux X server on Android in normal way, because init is different, libc is different and kernel is also different when it comes to display server. Android developers tried their luck to develop an X server for Android, like XServer XSDL. Though functional, these are very limited in functionality, mainly due to app sandboxing mechanism of Android. X server provides a basic security mechanism when started with "-auth" argument to use a cookie file (~/.Xauthority) i.e. using X authority, but Android app doesn't provide this options. Other option is Xvnc server which is X server + vnc server in a single package and unlike other vnc servers, it doesn't need a physical display. It runs X server in headless mode on a virtual display without need of a console connected to actual display. X server directs it output to vnc server which can be accessed from a vnc client (viewer) on localhost or remotely by entering the IP and port/display if phone is connected to network (wi-fi / hotspot).
Graphics, Input and Sound
DRM, evdev and ALSA drivers work in parallel inside Linux kernel.
Graphics:
Framebuffer (fbdev)
Traditional methods in which /dev/(graphics)/fb[N] device is provided by kernel which directly writes to GPU / graphics memory
Kernel is built with framebuffer driver (text console and video mode driver; fbcon), otherwise vesa generic driver can be used
Kernel Mode Settings / Direct Rendering Manager (KMS/DRM)
They live in kernel and exposed to userspace by device /dev/dri/card0
Gives more control over the graphics hardware
Mostly provided by hardware specific drivers as well
Xorg
Most commonly used method
Searches installed drivers for hardware specific drivers (Intel, AMD, Nvidia etc.); open source (mesa) or proprietary. Open source drivers also make use of libdrm for talking to kernel.
If not found, uses vesa generic driver, without acceleration
If not found, uses frambuffer device driver (fbdev)
If not found, uses KMS
xlib or xcb are used by clients for graphics output to X server; either directly or through widget toolkit libraries such as GTK or QT for the actual drawing of buttons, menus etc.
Android supports fbdev somewhat and X server can be configured to use fbdev driver. However, Qualcomm doesn't want you use msm framebuffer freely.
Input:
Hardware specific drivers such as for Synaptic Touchpad can be used but mostly two methods are used:
libinput
A userspace library developed by Wayland, but now implemented by Xorg as well (pointer, touchpad, touchscreen etc.)
evdev
Traditional Linux kernel generic driver (keyboard, mouse through USB, PS/2, PCI etc.) exposes input device through /dev/input/*
Android supports evdev and touchscreen can be used to operate Linux.
Sound:
Advanced Linux Sound Architecture (ALSA) is a set of kernel modules + libraries that exposes sound card status and configuration interface through /proc/asound.
ALSA kernel module (drivers) for sound card is loaded at boot ('cat /proc/asound/modules' or 'lsmod | grep ^snd') which controls device.
Most distros run a sound server PulseAudio which receives audio streams from client libraries ( used by music apps / mic etc.) and directs the output to hardware device (speaker / headphone etc.) through ALSA drivers. PulseAudio client can also forward sound to other PulseAudio servers on network or stream to network audio devices through local PulseAudio server.
Android supports ALSA but devices on Android are quite different than on PC's. There is also difference in ioctl calls both kernel support.
Android kernel is often compiled without LKMs support (CONFIG_MODULES=y).
Proprietary drivers of Android sound cards (msm*sndcardm on Qualcomm devices, 'cat /proc/asound/cards') and their configurations (/usr/share/alsa/cards) are not supported by ALSA on Linux distros.
Therefore sound won't work out of the box and manual configuration is needed to natively enable Linux sound on Android device. Android kernel populates control and PCM sound device interfaces in /dev/snd from /sys/class/sound which can be manipulated to direct ALSA towards Android sound card.
Native support for Linux multimedia (display and sound) can be enabled on running Android device by modifying framebuffer and PCM devices. However, it usually involves disabling functionality of these devices for Android when we are using them for Linux. It's due to the fact that though the base is same, there are differences in implementations.
As a general rule, even if we have a Linux distro running on an ARM device, it'd be nearly impossible to run it on other boards, irrespective of how much resemblance in specification is.
Click to expand...
Click to collapse
. . . continued . . .
ANDROID vs LINUX: FILESYSTEMS and MOUNTS
MOUNTS
ANDROID 8.0
Code:
rootfs on / type rootfs (ro,seclabel,size=1330868k,nr_inodes=332717)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=1436636k,nr_inodes=359159,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime,gid=3009,hidepid=2)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
none on /dev/memcg type cgroup (rw,relatime,memory)
debugfs on /sys/kernel/debug type debugfs (rw,seclabel,relatime)
tmpfs on /mnt type tmpfs (rw,seclabel,relatime,size=1436636k,nr_inodes=359159,mode=755,gid=1000)
none on /config type configfs (rw,relatime)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
none on /dev/cpuset type cgroup (rw,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent)
pstore on /sys/fs/pstore type pstore (rw,seclabel,relatime)
tmpfs on /storage type tmpfs (rw,seclabel,relatime,size=1436636k,nr_inodes=359159,mode=755,gid=1000)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,seclabel,relatime)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
/dev/block/platform/soc/7824900.sdhci/by-name/system on /system type ext4 (ro,seclabel,relatime,discard,data=ordered)
/dev/block/bootdevice/by-name/cache on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,data=ordered)
/dev/block/bootdevice/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,data=ordered)
/dev/block/bootdevice/by-name/dsp on /dsp type ext4 (ro,seclabel,nosuid,nodev,relatime,data=ordered)
/dev/block/bootdevice/by-name/modem on /firmware type vfat (ro,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro)
/dev/block/dm-0 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,data=ordered)
/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid)
/data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid)
/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23,derive_gid)
/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid)
UBUNTU 16.04
Code:
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1930528k,nr_inodes=482632,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=391184k,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14965)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=391184k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda3 on / type ext4 (rw,relatime,errors=remount-ro,stripe=32735,data=ordered)
/dev/sda7 on /F type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/sda5 on /home type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
FILESYSTEM TREE
ANDROID 8.0
Code:
4.9G /
2.9G /data
1.6G /system
1.1G /data/app
856M /data/data
807M /data/dalvik-cache
505M /data/dalvik-cache/arm64
387M /system/vendor
372M /system/priv-app
354M /cust
303M /data/dalvik-cache/arm
303M /cust/app
248M /system/app
245M /system/vendor/lib
159M /system/lib64
135M /system/vendor/lib64
110M /system/lib
/acct
/bin
/bt_firmware
/cache
/config
/dev
/dsp
/etc
/firmware
/mnt
/oem
/persist
/proc
/res
/root
/sbin
/sdcard
/storage
/su
/sys
/var
/vendor
UBUNTU 16.04
Code:
4.4G /
3.3G /usr
1.7G /usr/lib
1007M /usr/share
966M /usr/lib/x86_64-linux-gnu
458M /usr/bin
426M /lib
338M /var
218M /var/lib
216M /lib/modules/4.10.0-28-generic
216M /lib/modules
211M /usr/share/fonts
211M /lib/modules/4.10.0-28-generic/kernel
208M /home
159M /lib/firmware
134M /var/lib/apt
127M /usr/src
123M /usr/share/fonts/opentype
118M /usr/share/icons
115M /usr/lib/jvm
111M /usr/src/linux-headers-4.10.0-28
106M /usr/lib/thunderbird
/bin
/boot
/cdrom
/dev
/etc
/lib64
/media
/mnt
/opt
/proc
/root
/run
/sbin
/snap
/srv
/sys
/tmp
ANDROID vs LINUX: INIT PROCESSES and SERVICES
ANDROID 8.0
Code:
PPID PID TT CMD
0 1 ? /init
1 402 ? /sbin/ueventd
1 428 ? /system/bin/logd
1 429 ? /system/bin/servicemanager
1 430 ? /system/bin/hwservicemanager
1 431 ? /vendor/bin/vndservicemanager /dev/vndbinder
1 446 ? /system/bin/vold --blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 --fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0
1 458 ? /system/bin/hw/[email protected]
1 465 ? /vendor/bin/hw/[email protected]
1 460 ? /vendor/bin/hw/[email protected]
1 461 ? /vendor/bin/hw/[email protected]
1 462 ? /vendor/bin/hw/[email protected]
1 464 ? /vendor/bin/hw/[email protected]
1 466 ? /vendor/bin/hw/[email protected]
1 467 ? /vendor/bin/hw/[email protected]
1 468 ? /vendor/bin/hw/[email protected]
1 469 ? /vendor/bin/hw/[email protected]
1 470 ? /system/bin/healthd
1 476 ? /vendor/bin/sensors.qcom
1 472 ? /vendor/bin/rmt_storage
1 474 ? /vendor/bin/tftp_server
1 481 ? /system/bin/lmkd
1 477 ? /system/bin/gx_fpd
1 479 ? /vendor/bin/pm-service
1 480 ? /vendor/bin/qseecomd
480 568 ? \_ /vendor/bin/qseecomd
1 482 ? /system/bin/surfaceflinger
1 483 ? /system/bin/thermalserviced
1 485 ? /vendor/bin/pm-proxy
1 853 ? /vendor/bin/hw/[email protected]
1 2127 ? /system/vendor/bin/cnd
1 2129 ? /system/vendor/bin/ipacm-diag
1 2128 ? /system/vendor/bin/netmgrd
1 2130 ? /system/vendor/bin/qti
1 2131 ? /vendor/bin/hw/rild -c 2
1 2134 ? /system/vendor/bin/adsprpcd
1 2137 ? zygote64
2137 2267 ? \_ xposed_logcat
2267 2271 ? | \_ logcat -v time -s XposedStartupMarker:D Xposed:I appproc:I XposedInstaller:I art:F
2137 2984 ? \_ system_server
2137 3238 ? \_ com.android.systemui
2137 3351 ? \_ com.qualcomm.qti.telephonyservice
2137 3365 ? \_ com.android.phone
2137 3506 ? \_ com.qualcomm.qcrilmsgtunnel
2137 3993 ? \_ com.google.android.gms.persistent
2137 4020 ? \_ org.lineageos.audiofx
2137 4070 ? \_ com.android.smspush
2137 4089 ? \_ com.google.android.inputmethod.latin
2137 4106 ? \_ com.teslacoilsw.launcher
2137 4131 ? \_ org.lineageos.profiles
2137 4188 ? \_ com.google.android.gms
2137 4205 ? \_ com.google.process.gservices
2137 4569 ? \_ android.process.media
2137 5673 ? \_ com.google.android.gms.unstable
2137 5694 ? \_ org.lineageos.lockclock
2137 5747 ? \_ org.omnirom.omnijaws
2137 6128 ? \_ com.android.bluetooth
2137 7040 ? \_ android.process.acore
2137 7696 ? \_ com.google.android.inputmethod.latin:train
2137 8096 ? \_ com.android.vending.billing.InAppBillingService.COIN
2137 8923 ? \_ com.google.android.configupdater
2137 10345 ? \_ com.android.dialer
1 2136 ? /system/vendor/bin/hvdcp_opti
1 2133 ? /system/vendor/bin/thermal-engine
1 2135 ? /system/vendor/bin/imsqmidaemon
1 2139 ? /system/bin/audioserver
1 2138 ? zygote
2138 5142 ? \_ com.android.vending
1 2140 ? /system/bin/cameraserver
1 2141 ? /system/bin/drmserver
1 2142 ? /system/bin/installd
1 2144 ? /system/bin/keystore /data/misc/keystore
1 2145 ? /system/bin/mediadrmserver
1 2156 ? media.extractor aextractor
1 2165 ? /vendor/bin/hw/[email protected]
1 2158 ? media.metrics diametrics
1 2159 ? /system/bin/mediaserver
1 2160 ? /system/bin/netd
2160 2276 ? \_ /system/bin/iptables-restore --noflush -w -v
2160 2277 ? \_ /system/bin/ip6tables-restore --noflush -w -v
2160 7456 ? \_ /system/bin/dnsmasq-orig --keep-in-foreground --no-resolv --no-poll --dhcp-authoritative --dhcp-option-force=43,ANDROID_METERED --pid-file --listen-mark 0xf0063 --dhcp-range=192.168.43.2,192.168.43.254,1h
1 2161 ? /system/bin/storaged
1 2162 ? /system/bin/wificond
1 2164 ? /vendor/bin/hw/rild
1 2163 ? media.codec hw/[email protected]
1 2170 ? /system/bin/gatekeeperd /data/misc/gatekeeper
1 2167 ? /system/vendor/bin/loc_launcher
2167 2239 ? \_ slim_daemon --sap PREMIUM
2167 2240 ? \_ xtra-daemon
1 2169 ? /system/bin/mm-qcamera-daemon
1 2231 ? /system/vendor/bin/wcnss_service
1 2229 ? /system/bin/tombstoned
1 2249 ? /vendor/bin/mm-pp-dpps
1 2274 ? /vendor/bin/msm_irqbalance -f /system/vendor/etc/msm_irqbalance.conf
1 3319 ? /system/bin/webview_zygote32
1 3610 ? /system/vendor/bin/ims_rtp_daemon
1 3611 ? /system/vendor/bin/imsdatadaemon
1 3724 ? /system/vendor/bin/imsrcsd
1 7453 ? /vendor/bin/hostapd -e /data/misc/wifi/entropy.bin /data/misc/wifi/hostapd.conf
1 8459 ? /system/bin/adbd --root_seclabel=u:r:su:s0
1 8463 ? /system/bin/mdnsd
1 440 ? magisk_daemon -post-fs
440 10948 pts/3 \_ sh -c LD_LIBRARY_PATH=/tmp/mirfatif/lib /tmp/mirfatif/xbin/sh
10948 10951 pts/3 \_ /tmp/mirfatif/xbin/sh
10951 11206 pts/3 \_ /tmp/mirfatif/xbin/sh /tmp/mirfatif/bin/pss
11206 11207 pts/3 \_ /data/data/com.termux/files/usr/bin/ps f --ppid 2 -p 2 --deselect -o ppid,pid,tty,cmd
UBUNTU 16.04
Code:
PPID PID TT COMMAND
0 1 ? /sbin/init
1 328 ? /lib/systemd/systemd-journald
1 342 ? /lib/systemd/systemd-udevd
1 743 ? /sbin/mount.ntfs-3g /dev/sda7 /F -o rw,nosuid,nodev
1 744 ? /sbin/mount.ntfs-3g /dev/sda5 /home -o rw,permissions
1 775 ? /lib/systemd/systemd-timesyncd
1 871 ? /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
1 878 ? /usr/sbin/rsyslogd -n
1 880 ? /usr/sbin/vnstatd -n
1 881 ? /lib/systemd/systemd-logind
1 884 ? /usr/sbin/acpid
1 886 ? /usr/sbin/sshd -D
1 888 ? /usr/lib/bluetooth/bluetoothd
1 889 ? /usr/bin/freshclam -d --foreground=true
1 891 ? /usr/sbin/cron -f
1 892 ? /usr/sbin/thermald --no-daemon --dbus-enable
1 900 ? /usr/sbin/clamd --foreground=true
1 931 tty1 /bin/login --
931 1145 tty1 \_ -bash
1145 2192 tty1 \_ /bin/sh /usr/bin/startx
2192 2215 tty1 \_ xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.yDCz6R4byp
2215 2216 tty1 \_ /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.yDCz6R4byp
2216 2221 tty1 | \_ /usr/lib/xserver-xorg-video-intel/xf86-video-intel-backlight-helper intel_backlight
2215 2232 tty1 \_ /bin/sh /home/mirfatif/.xsession
2232 2267 ? \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch /home/mirfatif/.xsession
2232 2280 tty1 \_ /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
2280 2290 tty1 \_ xfce4-session
2290 2328 tty1 \_ /usr/lib/x86_64-linux-gnu/indicator-application/indicator-application-service
2290 2329 tty1 \_ lxpolkit
2290 2338 tty1 \_ xautolock -time 10 -locker xflock4
2290 2339 tty1 \_ dhcpcd-gtk
2290 2345 tty1 \_ indicator-keylock
2290 2356 tty1 \_ indicator-netspeed-unity
1 950 ? /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
1 964 ? wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf -iwlp2s0
1 971 ? /sbin/dhcpcd
1 1140 ? /lib/systemd/systemd --user
1140 1142 ? \_ (sd-pam)
1 1343 tty6 /sbin/agetty --noclear tty6 linux
1 1467 tty2 /sbin/agetty --noclear tty2 linux
1 2226 ? /usr/lib/policykit-1/polkitd --no-debug
1 2270 tty1 /usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch /home/mirfatif/.xsession
1 2271 ? /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
1 2295 ? /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
1 2299 ? /usr/bin/gpg-agent --sh --daemon --write-env-file /home/mirfatif/.cache/gpg-agent-info
1 2301 tty1 xfwm4
1 2305 tty1 xfce4-panel
2305 2390 tty1 \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libwhiskermenu.so 6 16777244 whiskermenu Whisker Menu Show a menu to easily access installed applications
2390 2517 tty1 | \_ /usr/lib/notepadqq/notepadqq-bin
2390 2526 tty1 | \_ xfce4-terminal --maximize
2526 2531 tty1 | \_ gnome-pty-helper
2526 2532 pts/0 | \_ bash
2532 10220 pts/0 | | \_ sudo chroot /alarm
10220 10221 pts/0 | | \_ /usr/bin/qemu-aarch64-static /bin/bash -i
2526 11207 pts/2 | \_ bash
11207 11435 pts/2 | \_ /bin/sh /bin/pss
11435 11436 pts/2 | \_ ps axf -o ppid,pid,tty,args
2305 2391 tty1 \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libindicator-plugin.so 7 16777248 indicator Indicator Plugin Provides a panel area for Unity indicators. Indicators allow applications and system services to display their status and interact with the user.
2305 2415 tty1 \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libsystray.so 15 16777249 systray Notification Area Area where notification icons appear
2305 2416 tty1 \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libpulseaudio-plugin.so 4 16777250 pulseaudio PulseAudio Plugin Adjust the audio volume of the PulseAudio sound system
2305 2417 tty1 \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libdatetime.so 11 16777251 datetime DateTime Date and Time plugin with a simple calendar
1 2307 tty1 Thunar --daemon
1 2309 tty1 xfdesktop
1 2310 ? xfsettingsd
1 2350 ? /usr/lib/dhcpcd-dbus/dhcpcd-dbus
1 2352 ? xfce4-power-manager
1 2358 ? /usr/lib/at-spi2-core/at-spi-bus-launcher
2358 2363 ? \_ /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
1 2365 ? /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
1 2375 ? /usr/lib/gvfs/gvfsd
1 2376 ? /usr/lib/upower/upowerd
1 2386 ? /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
1 2444 tty1 upstart --user --startup-event indicator-services-start
1 2449 ? /usr/bin/pulseaudio --start --log-target=syslog
1 2452 ? /usr/lib/rtkit/rtkit-daemon
1 2474 ? /usr/lib/gvfs/gvfs-udisks2-volume-monitor
1 2477 ? /usr/lib/udisks2/udisksd --no-debug
1 2485 ? /usr/lib/gvfs/gvfs-goa-volume-monitor
1 2490 ? /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
1 2495 ? /usr/lib/gvfs/gvfs-afc-volume-monitor
1 2501 ? /usr/lib/gvfs/gvfs-mtp-volume-monitor
1 2509 ? /usr/lib/gvfs/gvfsd-trash --spawner :1.29 /org/gtk/gvfs/exec_spaw/0
1 2741 tty1 /opt/google/chrome/chrome
2741 2750 tty1 \_ /opt/google/chrome/chrome --type=zygote
1 2812 ? /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
1 9366 ? /usr/lib/gvfs/gvfsd-metadata
1 10910 ? adb -P 5037 fork-server server
Why Linux-on-Android? And Possible Methods of Android-Linux Dual Booting
. . . continued . . .
When there are so much differences,
WHY WE NEED TO INSTALL LINUX ON ANDROID DEVICE?Because Android is non-POSIX Linux. Though kernels are very same (only a few syscalls differ), C libraries are quite different making it impossible to run every Linux program on Android natively.
Since Android has its origins from Linux, it can be considered a highly customized embedded Linux (distro?); mainly for ARM processors and Qualcomm SoC's. Android, unlike PC's, exposes users to a limited Linux and we can't utilize powers of Linux. This limited nature is justified somewhat considering the less powerful hardware resources and "mobile" nature of the devices, Android is designed for. Restricted access to core OS is necessary for security and privacy of users who want a ready made perfectly working out-of-the-box type solution. For those who want some more from Android device, the first thing to do after buying a device is unlocking bootloader and "root" the device. This makes possible at least the user access to shell (CLI), which is the biggest common feature Android shares with Linux. Then to compensate the absence of glibc, busybox type handy solution is availed. But it's designed with a small number of commandline utilities and that too with limited functionality.
You don't have access to repositories of thousands of free packages available for a wide variety of tasks, almost anything you can think of.
While on Android, even you don't have an option to encrypt your SD card.
Or you need to encrypt a folder containing your private pics for online backup?
Or what if you accidentally deleted some important stuff on internal memory and want to recover that?
Or if you want to make your device a tiny server for easy access from other phone or PC?
Android provides very limited data backup options as compared to Linux.
Compile programs in full environment
You are totally dependent on apps and their developers to achieve all this, what functionality they offer and what they do to you and to your private data. Thus one may wish to install Linux on an Android device.
And after all it's fun to have a phone with many possibilities that could be played with. Be a power user!
CHROOT, NAMESPACES, CONTAINERS and VMDue to (almost) same kernel, it's the chroot operation of Unix-like OS's which makes it possible to provide an isolated environment for new apps or a new OS inside a running OS without needing a dedicated rootfs. You can also use hardware emulator like QEMU to run cross-architecture Linux OS. Even Windows can be run in an emulator on Android device if your hardware has capability such as on Limbo PC Emulator. But it will be unbearably slow. Let's make a comparison of methods used to isolate OS environments on a single machine.
CHROOT
Chroot just changes the root of single or more processes, not booting a new OS, thus changing the filesystem hierarchy and binary environment for applications.
OS's still can view each others' processes, mounts etc. because every process is running on same OS natively.
Can't start init process and spawn all services and daemons like syslogd, cron etc. from it. Need to just start the required processes manually.
NAMESPACES, CGROUPS AND CONTAINERS
Containers are kernel feature which additionally make use of namespaces and cgroups to isolate the guest OS from host.
Namespaces limit what resources a process can see and use, while cgroups limit how much a process can use a resource.
Network namespaces provide isolated view of iface, firewall rules and sockets. It is necessary so that daemons like sshd can be started independently.
Mount namespace hides Linux mounts from host OS (Android in our case) or even from spawned processes. As well as it gives flexibility to unmount / move / remount all Android shared filesystems except rootfs (pivot_root fails on Android
User namespace maps unused UID/GID's on host (like higher number 10000) to the UID's/GID's of the guest thus avoiding conflict of identical ID's and letting ID's work independently. It also restricts unwanted access from guest to host OS.
UTS NS allows setting hostname independent of Android.
PID NS will show only Linux processes, not those of Android.
cgroups (/sys/fs/cgroup) and cgroup namespaces (/proc/[pid]/cgroup) make it possible to group processes with a defined limit on allocated system resources (RAM, CPU, I/O i.e. storage devices, network, devices allocation).
But both OS share same kernel, drivers and modules, using process isolation methods provided by Linux kernel.
Can't boot different OS's with incompatible kernels.
All hardware related stuff is handled by host kernel.
RAM allocation to running processes and CPU usage can be managed more efficiently by a single kernel with negligible overhead because namespaces and cgroups are already being used by host OS to manage it's own processes.
VIRTUAL MACHINES
Hypervisors or virtual machines (kvm, VirtualBox etc.) emulate the hardware and provide a complete machine environemnt to use an independent kernel (and even a bootloader and BIOS as well), booting any OS which the virtualizer is compatible with.
Guest kernel thinks it's dealing with the real hardware, not emulated.
So there is a thick layer of software stack between OS and actual hardware, making it very slower.
Hardware resources are divided in between kernels and are allocated / managed independently.
Native or bare-metal hypervisors like Xen and Hyper-V give better performance as they talk directly to hardware, not through an OS.
systemd-nspawn is an isolation method provided by systemd and is very popular in containerization these days. It's something in between chroot and containers (LXC, docker etc.)
PERFORMANCE & SECURITY
Performance: chroot > containers > virtualization
Isolation: chroot < containers < virtualization
In a nutshell, chroot needs more human effort to setup because it varies from device to device but it's least overhead on system resources.
LINUX CONTAINERS, CHROOT & PIVOT_ROOT ON ANDROID
We need a modified Android kernel with support for containers, pivot_root and all namespaces etc. Android by default supports entering namespaces using init .rc files on boot before starting a process.
In order to hide mounts from host, we can make use of mount namespace with private or slave propagation.
In order to hide future mounts from guest, we can make use of mount namespace with private propagation.
Already mounted mounts can be hidden from guest by using "unshare + pivot_root + chroot" (or may be "unshare + mount --move + chroot" as referred here, but so far can't figure out how). But pivot_root doesn't work on Android because of special kernel loading process. Unlike Linux, Android rootfs mounted from initramfs is retained and pivot_root is not used in booting process to switch rootfs to real hard drive partition.
So, we have to rely on namespaces + chroot combination. "unshare + chroot" both work on Android devices, though busybox 'unshare -m' doesn't work.
Only MNT and NET namespaces work on Android devices by default. PID, UTS and USER namespaces can be enabled by rebuilding kernel.
Moving towards practical details:
[HOW TO] INSTALL LINUX ON ANDROID DEVICE (LINK TO COME)
That's all from my side. You can correct me if I'm wrong or complete me if I missed something worth mentioning.
Permissions, Root User and Linux Capabilities: Linux vs. AndroidLinux makes use of file permissions (DAC, MAC) and file / process capabilities to restrict access to system resources such as files on a certain filesystem. SELinux and AppArmor are commonly used Mandatory Access Control systems. Discretionary Access Controls include classic UNIX RWX file modes, owner/group or UID/GID, Extended Attributes and Access Control Lists. XATTR and ACL are rarely used filesystem related attributes. DAC and Linux Capabilities are closely related. Filesystem capabilities are of three categories: Inheritable, Permitted and Effective, while processes have two additional types: Ambient and Bounding. A process with complete set of effective capabilities is said to have root privileges. Root user can bypass all permission checks imposed by kernel. So the kernel checks for effective UID and effective process capablities for permission checks.
Android users are not allowed to have admin privileges by default. Rooting is the process of gaining these privileges with user ID 0 and all Linux capabilities, which are dropped for common human users with nonzero user ID's. A user is basically a set of privileges/capabilities identified by a number (UID). All processes running under a user have same privileges. These privileges can be dropped and elevated depending on some conditions.
In Linux boot process, kernel starts "init" process with all capabilities i.e. as root. Subsequently different processes are started with different required capabilities/privileges. On completion of boot process when reaching a human user shell (at login), effective capabilities are dropped to minimal but bounding set is maintained so that effective capabilities can be elevated later on when required using some method such as libcap. So, the privileged tasks can be performed in two ways:
Using setuid
An executable binary with suid bit set (a DAC file attrib set by command 'chmod u+s') will always run as root user. Setuid flag (set-user-id root) is equivalent to setting file's permitted and effective capabilities to all capabilities. CAP_SYS_ADMIN alone is almost near to all capabilities. Linux programs "su" and "sudo" makes use of "setuid" to gain effective UID 0 for temporarily performing some task with elevated privileges.
Using capabilities
To start a process with refined elevated privilege and not fully root (on per user base), set appropriate file capabilities on executable binaries and start processes at login with appropriate capabilities using PAM (making use of libcap). File capabilities are extended attribs set by command 'setcap' e.g. 'setcap cap_net_admin+ep' and 'setcap cap_net_raw+ep'. Check links (1, 2, 3, 4) to see how a new process's capabilities depend on executable file's capabilities and parent process's capabilities.
A brief description is being given here.
Effective UID is used for most access checks, and is the owner UID for files created by that process
File system user ID (FSUID) equals EUID unless (NFS, SDCARDFS etc.) filesystem is mounted with fsuid= option
An unprivileged process (non-root) can change its EUID only to either its SUID or RUID. If EUID=0, it can be changed to anything.
Saved UID is the priveleged UID saved by a process running with elevated privileges before it temporarily lowers its privileges
After executing unpriveleged task, saved-UID is restored back
If a set-user-ID program is executed, saved-UID is the owner UID of file. Otherwise saved-UID = RUID
Real UID (RUID) is the UID of user starting the program. It controls which user can send signals to other program
An unprivileged process (non-root) can signal another process only if the sender’s RUID or EUID matches the receiver's RUID or SUID
A set UID (set-user-ID) program can switch between the UID of the user who invoked it (RUID), and the owner of the executable i.e. can change effective UID (EUID)
set-user-ID bit is ignored if prctl: NO_NEW_PRIVS operation is performed on calling process, or if filesystem is mounted with "nosuid", or if process is being ptrace'd (strace)
Same is for setgid
Code:
fI/fP : File's Inheritable/Permitted capabilities
fE : File's Effective capabilities bit
pI : Process's initial Inheritable capabilities; not generally preserved when running as a non-root user
X : Process's initial Bounding set; a security mechanism; inherited from parent; init begins with full set
Can be dropped by a thread by prctl: PR_CAPBSET_DROP operation, if process has CAP_SETPCAP in pE; cannot be gained once dropped
Can be read using prctl: PR_CAPBSET_READ
pP : Process's initial permitted capabilities; if dropped, can't be reacquired without executing a privileged program binary
pI'/pP'/pE' : Process's new Inheritable/Permitted/Effective capabilities
pA : Ambient capabilities; preserved across execution of a program that is not privileged
Can be raised by prctl: PR_CAP_AMBIENT_RAISE operation, but overridden by setting SECBIT_NO_CAP_AMBIENT_RAISE on calling process
How capabilities are preserved when switching user (su; using setuid or setresuid):
If one/more of EUID/RUID/SUID is 0, and all 3 become non-zero , then pP', pE' and pA' are cleared
pP' and pE' can be preserved by setting SECBIT_KEEP_CAPS, but flag is cleared on every execve
If EUID is 0, and becomes non-zero, then pE' is cleared
If EUID is non-zero, and becomes 0, then pE'=pP
Setting SECBIT_NO_SETUID_FIXUP preserves all capabilities in pP', pE' and pA' when EUID changes
How capabilities are preserved when not exec'ing or fork'ing a process (using "capset" syscall as libcap / "pam_cap" module do):
Any task can remove capabilities from pE, pP, or pI at any time
If a task has a capability in pP,
It can add that capability to pI' masked by X
It can add that capability to pP'
It can add that capability to pE masked by pP'
If a task has CAP_SETPCAP, it can add any capability to pI, and it can remove capabilities from X
How capabilities are preserved when fork'ing a process:
All capabilities are preserved
How capabilities are preserved when exec'ing a process:
pA' = (file caps or setuid or setgid ? 0 : pA)
pA' = (pP' & pI') i.e. a capability is automatically dropped from pA' if that is dropped from pP' or pI'
Preserved when executing non-priveleged programs, cleared otherwise
pP' = (X & fP) | (pI & fI) | pA'
Cleared if calling process is non-root user (and if pA is empty?)
For dumb binaries, if X masks out some capabilities in fP, execution fails (to ensure that dumb binaries aren't executed with less than required privileges)
If file is set-user-ID-root or calling process has EUID 0, and X is full set, then pP' is also full set
If calling process has RUID 0, and X is full set, then pP' is also full set
pI' = pI (for root user)
pI' = (pI & pP) if user doesn't have CAP_SETPCAP in pE, so not preserved when running as a non-root user (i.e. with no pP and no pE)
pE' = (fE ? pP' : pA')
If fE bit is set for a capability, that capability in pP' (acquired from fP or fI) is also added to pE', otherwise ambient capabilities are assigned to the effective set
It means fI or fP won't appear in pE' if fE isn't set (for capability-dumb binaries)
Cleared if calling process is non-root user (and if pA is empty?)
If file is set-user-ID-root or calling process has EUID 0, and X is full set, then pE' is also full set
X is unchanged unless changed by capset
Privileged program/binary file is a program that has set-user-ID or set-group-ID bits or has any file capabilities set
Setting file capabilities requires CAP_SETFCAP
File capabilities are ignored if prctl: NO_NEW_PRIVS operation is performed on calling process, or if filesystem is mounted with "nosuid", or if process is being ptrace'd (strace)
A capability-dumb binary is a program that has file capabilities (even if empty capability set), but has not been converted to use the libcap API to manipulate its capabilities. Kernel consider a binary dumb if fE bit is set
A file with set-user-ID-root is considered to have full set of fI and fP, and fE bit set, same is considered if calling process has RUID or EUID 0
This can be overridden by setting SECBIT_NOROOT on calling process
File capabilities take precedence over setuid (even if empty capability set), though EUID and SUID becomes 0 if file is set-user-ID-root. But to make setuid effective for gaining all capabilities, execute 'setcap -r' or 'setfattr -x security.capability' on binary to remove xattr from file completely.
SECBIT Flags:
Can be locked to prevent further changes
Can be modified and retrieved using the prctl: PR_SET_SECUREBITS and PR_GET_SECUREBITS operations. CAP_SETPCAP is required for modification
Are preseved when fork'ing and execve'ing, except SECBIT_KEEP_CAPS is cleared on execve
Android restricts all of its apps (Java virtual machines) from gaining elevated privileges (by ignoring setuid and file capabilities) by setting PR_SET_NO_NEW_PRIVS as explained here and here. So the apps cannot run a binary with set-user-ID-root as root process because they (users/processes) don't have CAP_SETGID in Bounding Set (X).
Additionally a special patch CONFIG_ANDROID_PARANOID_NETWORK was applied to Linux kernel which maps certain capabilities to certain groups. For instance, user without CAP_NET_RAW capability cannot access internet. But Android allows users belonging to group AID_INET (3003) to create network sockets. However it's not applicable to raw sockets, commonly used by ping for echoing. Android's ping binary creates UDP sockets (uses SOCK_DGRAM in place of SOCK_RAW) in order to work without any special privileges (i.e. without CAP_NET_RAW).
So when using Linux on Android device, we need to add the user to group inet 3003 using /etc/group which is read at login by PAM and login programs (su, login, ssh etc.).
On Linux user login, PAM modules set process (login shell usually) capabilities according to its user / groups (uid, gid, secondary groups) as set in login files (/etc/{passwd,group} etc.) and PAM modules (such as pam_cap.so) can be configured to set desired capabilities for a user/group. Login files also let assign a name for a UID/GID to remember easily. But there is no login mechanism on Android and hence no pam/libcap to set required processes capabilities at runtime. However ambient capabilities (along with Permitted, Effective and Inheritable) for boot processes/services can be set from init *.rc files or filesystem capabilities can be set on binaries while building ROM.
In addition to Linux's access control mechanisms, Android enforces it's own manifest permissions control to installed apps within its Java framework. However, as explained above, some of the permissions are associated with UIDs and GIDs to enforce filesystem access control at kernel level. A common example is permission android.permission.INTERNET associated with group inet (GID 3003), necessarily required to create network sockets i.e. to access internet. Further reading: Android's permissions mapping with UIDs/GIDs.
RESERVED
nice