Database Users

gTablet-TapUI-1.1-Kernel-Patch -- Summary and Analysis

Now that we have the kernel source patch, I thought it would be good to summarise what's in it.
I've made a start here:
https://spreadsheets.google.com/ccc?key=tqj3aStfFS2K5PO83we84TQ&authkey=CI6h0aMD#gid=0
Because we don't have a full changelog, and it's a big patch, I thought it would be helpful to summarise what was changed in each file which brief comments. If you can help fill in the gaps for the modified files please post below.
Note that the patch appears to include a lot of cruft (multiple redundant backup copies of some files) I'd like to verify which files are redundant and produce a filtered, simplified patch. If you can confirm that the marked files are redundant that would be helpful.
I note that there are a few points where there is debug code and fixme comments in the patch. These may point to areas where things were never quite worked out (eg power management?). I don't have enough experience to look into this more deeply but just thought I'd mention it here.
Finally, the mmc driver has been brought in from outside the nv-tegra tree. It would be useful to generate a diff against the mainline tree to understand what (if anything) has changed there.
Happy Christmas!

I'm not very android dev savvy either...but they may have left the old drivers in there because old ROMs refer to them and they wanted to preserve the ability to go back to previous ROMs? -- that is...if the ROMs reference the kernel for drivers...not quite sure how that whole thing works...just a thought.

I've built a kernel from these sources, but unfortunately the bootloader throws a "magic value mismatch" error rather than booting the kernel. Has anybody else had any better luck?
EDIT: my bad, I replaced the boot.img with the raw zImage. I now have it booting my kernel, but it dies like this when starting Android:
I/SurfaceFlinger( 1072): SurfaceFlinger is starting
I/SurfaceFlinger( 1072): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
D/Zygote ( 1070): Process 1072 terminated by signal (11)
I/Zygote ( 1070): Exit zygote because system server (1072) has terminated

Any lines starting with - are deleted code.

NMCBR600 said:
Any lines starting with - are deleted code.
Click to expand...
Click to collapse
Yeah, in the patch itself, lines starting with + are added, and starting with - are deleted.
In the spreadsheet linked above, lines starting with + are files added, -files deleted, and !modified.
Actually the patch deletes no files, but /arch/microblaze/boot/dts/system.dts is overwritten with a new one. Anyone know exactly what that file does?
I started this because when I was reading the patch it seemed like a lot of new files were added and I wanted to work out where they came from, but it now looks like a lot of the added files are just backup copies the Malata dev has left in the tree (not a bad programming practice during development, but makes the patch a bit confusing to read).
Seems like the new files that are added (that aren't backups) are:
+ touch screen drivers in arch/arm/mach-tegra/odm_kit/platform/touch/{ak4183,at168}
+ driver for buttons in drivers/input/keyboard/so340010_kbd.c
+ drivers for gps control (power on/off), light sensor and accellerometer in drivers/input/misc/{gps_control.c,isl29023_ls.*,lis35de_accel.*}
+ drivers for batteries in drivers/power/smba10xx_battery and drivers/power/yoku_0563113
+ drivers for headphone and dock switches in drivers/switch/{switch_dock.c,switch_h2w.c} (header file in include/linux/switch_dock.h)
Also, mmc driver (presumably from mainline linux) is imported drivers/mmc

+ drivers for gps control (power on/off), light sensor and accellerometer in drivers/input/misc/{gps_control.c,isl29023_ls.*,lis35de_accel.*}
Sounds promising ..

Can someone explain to me perhaps if I'm missing something here- but what I am to understand from this post is that we finally got the source for the gtablet kernel? Would this incline to mean that we could compile the touchscreen and etc drivers onto a standard linux kernel and pop ubuntu or other such on the gtablet?
Or is 'patch' referring to just some small subset of the code missing the majority required to compile a gtablet kernel?
Any chance we might then be able to hack a fix into the accelerometer code to align the axis correctly?

rswindle said:
Can someone explain to me perhaps if I'm missing something here- but what I am to understand from this post is that we finally got the source for the gtablet kernel? Would this incline to mean that we could compile the touchscreen and etc drivers onto a standard linux kernel and pop ubuntu or other such on the gtablet?
Click to expand...
Click to collapse
One would have to recompile Ubuntu (or whatever distro) for ARM. Also, a finger friendly GUI would have to be added allowing the Capacitive screen to do its thing. Its very possible now with the kernel but no, you cannot use the iso downloaded from ubuntu.com.

rswindle said:
Can someone explain to me perhaps if I'm missing something here- but what I am to understand from this post is that we finally got the source for the gtablet kernel? Would this incline to mean that we could compile the touchscreen and etc drivers onto a standard linux kernel and pop ubuntu or other such on the gtablet?
Or is 'patch' referring to just some small subset of the code missing the majority required to compile a gtablet kernel?
Any chance we might then be able to hack a fix into the accelerometer code to align the axis correctly?
Click to expand...
Click to collapse
The drivers for the touchscreen, battery, and the accelerometer are all there in the kernel patch or the Nvidia tegra2 repo that it's patched again, yes. It's up on Viewsonic's website, in the support section.
Yes, you can merge them into an Ubuntu kernel if you want to. I'm sure somebody will do that in the next few weeks/months, it just hasn't happened yet since we just got the code dropped a few days ago.
There's some threads in NVidia's tegra2 dev forums on getting Ubuntu to work with a tegra 2 kernel. I posted the link earlier today if you're curious, look through my posts.

Great, so then the next question is, has anyone yet gotten a bootable compiled kernel from these yet?
Would be cool to get a stock android system compiled against a standard kernel for gtab.
Now I'm going to have to go rig up a linux thumb when I get home to start compiling the kernel with the patched sources and see what I can do. I so want to fix the damn accelerometer..
Best of all, my wife can play angry birds the entire time so she won't complain our HTPC is being used for my insanity..
Any suggestions what's a super lite fast distro to toss on a thumb quick that would quickly have me in position to git linux sources and compile this kernel? I don't keep up with the distros these days..

Yes
rswindle said:
Great, so then the next question is, has anyone yet gotten a bootable compiled kernel from these yet?
Would be cool to get a stock android system compiled against a standard kernel for gtab.
Now I'm going to have to go rig up a linux thumb when I get home to start compiling the kernel with the patched sources and see what I can do. I so want to fix the damn accelerometer..
Best of all, my wife can play angry birds the entire time so she won't complain our HTPC is being used for my insanity..
Any suggestions what's a super lite fast distro to toss on a thumb quick that would quickly have me in position to git linux sources and compile this kernel? I don't keep up with the distros these days..
Click to expand...
Click to collapse
I believe at least a half dozen of us have now built and deployed our own kernels. I've started cherry-picking Nvidia fixes beyond the baseline looking for something to fix the slowdown problem. Trying the latest variation now.
As for the accelerometer, I don't play any games where that is an issue, so I don't know if this resolves the problems, but there is a 1 line patch beyond our baseline in the Nividia tree which switches the X axis. Maybe this is the issue?
The patch description is:
X direction needs to be reversed to correct orientation in portrait
mode for Whistler.
Bug 678250
and the code diff is here:
http://nv-tegra.nvidia.com/gitweb/?...ff;h=6d57f00bb8276e0392dfa199017fc70fcea7d60b
I have applied this in my current kernel, but I've never seen the bug and can't tell you if it makes a difference.

[email protected] said:
I believe at least a half dozen of us have now built and deployed our own kernels. I've started cherry-picking Nvidia fixes beyond the baseline looking for something to fix the slowdown problem. Trying the latest variation now.
As for the accelerometer, I don't play any games where that is an issue, so I don't know if this resolves the problems, but there is a 1 line patch beyond our baseline in the Nividia tree which switches the X axis. Maybe this is the issue?
The patch description is:
X direction needs to be reversed to correct orientation in portrait
mode for Whistler.
Bug 678250
and the code diff is here:
http://nv-tegra.nvidia.com/gitweb/?...ff;h=6d57f00bb8276e0392dfa199017fc70fcea7d60b
I have applied this in my current kernel, but I've never seen the bug and can't tell you if it makes a difference.
Click to expand...
Click to collapse
mdwalker, I've likewise built my own kernel and have been running it too. I likewise have been trying to isolate and fix the slowdown problem. I likewise haven't succeeded yet.
There are a bunch of patches in the Nvidia tree that relate to suspend-resume issues, which I'm sure you've noticed. Let me know if you zero in on anything.

question.. I noticed all the developers are from Nvidia, I would think they would be Viewsonic developers... and if not the case are these bugs were not caught a while ago?

Viewsonic doesn't make this
stanglx said:
question.. I noticed all the developers are from Nvidia, I would think they would be Viewsonic developers... and if not the case are these bugs were not caught a while ago?
Click to expand...
Click to collapse
Viewsonic doesn't make our tablet, it's made by a Chinese company called Malata based on a standard Nvidia design. Viewsonic just resells it in the US.
There are actually a number of "rebadged" variations of this tablet, with more appearing almost every day.

Absolutely
rcgabriel said:
mdwalker, I've likewise built my own kernel and have been running it too. I likewise have been trying to isolate and fix the slowdown problem. I likewise haven't succeeded yet.
There are a bunch of patches in the Nvidia tree that relate to suspend-resume issues, which I'm sure you've noticed. Let me know if you zero in on anything.
Click to expand...
Click to collapse
Yes, I've certainly noticed the suspend/resume functionality looks to be a frequent source of "fixes". There are lots of patches which sound promising. Hopefully one (or more, gah!) will do the trick without having to hack up the cpu power management itself.
Likewise if you (or pershoot, or ... whomever else is tinkering) finds the right combination, please let us know!

Understand that... The point I am making is why is there so much Nvidia development going on for a version of the Kernel that is considered stable?
[email protected] said:
Viewsonic doesn't make our tablet, it's made by a Chinese company called Malata based on a standard Nvidia design. Viewsonic just resells it in the US.
There are actually a number of "rebadged" variations of this tablet, with more appearing almost every day.
Click to expand...
Click to collapse

rswindle said:
Now I'm going to have to go rig up a linux thumb when I get home to start compiling the kernel with the patched sources and see what I can do. I so want to fix the damn accelerometer..
Click to expand...
Click to collapse
Don't waste your time on the accelerometer, as the problem is with the app devs, not our device.
A nice explanation is here: http://android-developers.blogspot.com/2010/09/one-screen-turn-deserves-another.html

iptables owner module
One of the critical features I am looking for is a kernel built with support for iptables, and specifically the "owner" module.
This is used by apps such as Droidwall and my own app, Orbot, which is the port of Tor to Android. I worked with Cyanogen on this issue previously and am hoping to get this into all of the ROMs for the GTablet as well.
Thanks!

stanglx said:
Understand that... The point I am making is why is there so much Nvidia development going on for a version of the Kernel that is considered stable?
Click to expand...
Click to collapse
Why are you considering it's stable? Afaik there are very few products running the NVIDIA kernel at this stage -- the base hardware target is "harmony", which is actually one of NVIDIA's development boards.
G Tablet is one of the first Tegra 2 based products and we are about to see a whole raft of them over the next 6 months. Starting with Gingerbread tablets and then going to Honeycomb. If you check the logs you'll see that stuff from nv-tegra repo is being merged into the AOSP repo pretty regularly at the moment. Presumably, preparing for the Motorola Tegra 2 tablet. I imagine NVIDIA devs are quite busy on that.

I think a bigger question is why the very different codes at kernel.org and Navdia's own repository? In some cases commits are pulled in from each other, but clearly they are on different paths. Motorola seems to be pushing commits to kernel.org.
s_frit said:
Why are you considering it's stable? Afaik there are very few products running the NVIDIA kernel at this stage -- the base hardware target is "harmony", which is actually one of NVIDIA's development boards.
G Tablet is one of the first Tegra 2 based products and we are about to see a whole raft of them over the next 6 months. Starting with Gingerbread tablets and then going to Honeycomb. If you check the logs you'll see that stuff from nv-tegra repo is being merged into the AOSP repo pretty regularly at the moment. Presumably, preparing for the Motorola Tegra 2 tablet. I imagine NVIDIA devs are quite busy on that.
Click to expand...
Click to collapse

SE Android - ROM for Thunderbolt

So it seems the NSA has released their source code for SE Android (previously they built SELinux as well). This is a more sandboxed and secured version of Android based on the work they did in Linux.
This is the basis for Government grade secure Android devices that they are intending to deploy.
The build instructions list using AOSP as the basis and building from there, as it's primarily kernel compiling. That being the case you could (theoretically) kang almost any rom by recompiling and repackaging. I have not released any rom's or anything like that, so this (for now) would be nothing more than a packaged release of vanilla AOSP + SE Android kernel. As I get my feet under me I might tinker with some customizing, but wanted to see if there was an interest, otherwise I will just knock it out for me and skip updating.

i'm interested to see what you can come up with. Develop is slow here so anything is greatly appreciated. I came from the hd2 and development there is still awesome.

Interested. Have any links for code information as to what they did to implement security?
Sent from my ADR6400L using Tapatalk

Sure thing:
Turd Furguson said:
Interested. Have any links for code information as to what they did to implement security?
Sent from my ADR6400L using Tapatalk
Click to expand...
Click to collapse
http://selinuxproject.org/page/SEAndroid
Looks like mostly they ported the SE linux stuff over.

I'm also interested in this, I'm planning on releasing a build of this spliced with CM7 on Rootzwiki, since nobody else had started it yet.
They've mostly only made the major pieces of SELinux working with the Android kernel, and have a few userspace modifications on top of that. It'd be alot more C/C++ work than Java I'm afraid if specific tweaks need to be built.
I'm planning on beginning work when I get back to the U in a few days. Will you have a repo we can pull from for building? I have distributed compiling capabilities and we're on a shared 300meg link, I can build/upload if you'd like from your base?

At a workshop I attended to present a research paper of my own back in October there was discussions of building hypervisors into Android to separate out normal app space & business(secure) app space such that even if you had an evesdropping bit of malware it couldn't listen in on the business phone app as it was separated from the normal app space where the malware would live. But tie that into a SELinux style android kernel would likely make it significantly more beneficial.
I wonder how hard it would be to put the two together? Or if SEAndroid would defend against such threats on its own w/ out needing to build in hypervisor level security as well? Guess it might be worth investigating but definitely interesting and excited to look at further. Thanks for posting!!

I'm interested!

I wonder if the CM team would consider merging this into their builds, that would put it in a league of its own...a powerful ROM with many enhancements and exceedingly secure...just awesome.

I'd be interested in this. I just stumbled upon the whole SEAndroid thing while looking for ways to secure Android from some (seemingly?) legitimate apps that nevertheless ask for massive permissions (i.e., Juicedefender). It's just extremely difficult these days to tell, as often these sensitive permissions may actually be needed by the app to conduct its business.
I've actually been waiting on taking the plunge to root my phone (yes, overcaution, I know)...a strong, secure ROM based on SEAndroid would make me do it!

I would be interested in this also.

any development for the tbolt here is welcome. id be interested to see how this plays out. thanks for the hard work im sure your putting into it

[INFO] Linux kernel 3.3 released with merged Android code and more

Quoted from Engadget:
The latest refresh of the Linux kernel, 3.3, is now available, and the second release of 2012 brings with it the long-awaited merging of code from Google's little side project. While that is particularly interesting to developers looking to boot Android or run apps on the stock Linux kernel (FYI: optimized power management and other infrastructure that didn't make it this time will arrive in the next release, 3.4) and represents a resolution to the issues that kept the two apart for so long it's not the only new feature included. There are improvements to file systems like Btrfs, memory management, networking, security and much, much more. Hit the source link below for the full changelog or grab the code and from the usual locations and get your compile on directly.
Source: Engadget, Kernel Newbies, LKML.org
Any devs interested in developing a kernel based on this?
Based on what I read, this release would make it easier for us to compile the kernel as it brings merged Android code.

To me I'm thinking Google will Roll this out to the Nexus Line Up on the Next OTA... Perhaps the delay for the Nexus S if Due To This?
- Google

nice I hope so

iGoogleNexus said:
To me I'm thinking Google will Roll this out to the Nexus Line Up on the Next OTA... Perhaps the delay for the Nexus S if Due To This?
- Google
Click to expand...
Click to collapse
I doubt this is due to any delays regarding ota update, AFAIK, the Android devs at Google have all their own modules etc that they roll in to an update etc. This should however make projects like Ubuntu on Android etc easier.
Sent from my A500 using xda premium

glennkaonang said:
Quoted from Engadget:
The latest refresh of the Linux kernel, 3.3, is now available, and the second release of 2012 brings with it the long-awaited merging of code from Google's little side project. While that is particularly interesting to developers looking to boot Android or run apps on the stock Linux kernel (FYI: optimized power management and other infrastructure that didn't make it this time will arrive in the next release, 3.4) and represents a resolution to the issues that kept the two apart for so long it's not the only new feature included. There are improvements to file systems like Btrfs, memory management, networking, security and much, much more. Hit the source link below for the full changelog or grab the code and from the usual locations and get your compile on directly.
Source: Engadget, Kernel Newbies, LKML.org
Any devs interested in developing a kernel based on this?
Based on what I read, this release would make it easier for us to compile the kernel as it brings merged Android code.
Click to expand...
Click to collapse
I have been porting Samsung drivers for Nexus S for some time till Linux 3.3 RC3..
Sorry, no fully working results yet due to many code improvements..
But the work is in progress.. I'll also try to write so Samsung to get the info about their plans and/or the results of porting this code to 3.3

novic_dev said:
I have been porting Samsung drivers for Nexus S for some time till Linux 3.3 RC3..
Sorry, no fully working results yet due to many code improvements..
But the work is in progress.. I'll also try to write so Samsung to get the info about their plans and/or the results of porting this code to 3.3
Click to expand...
Click to collapse
Thanks for your hard work, man.
Anyway, after some readings, I think it's better for us to wait until 3.4 is released.
It is said that 3.4 will finish all the Android code merging process, with many fixes of course.
I'm no dev at all, so this is just a plain opinion from somewhat avid Android user
Sent from my Nexus S using xda premium

Cool

Compiling Android sources on the Pi

Hi Folks
Recently I helped Adam Outler get adb compiled for his Pi This was not as simpe as it first sounds because as we learnt adb on the host is subtlety different from the one compiled for the target and the AOSP source tree does not support compiling androids host tools for arm out of the box.
However You can add the armv6l host support by creating the file
Code:
<aosp source root>/build/core/combo/HOST_linux-armv6l.mk
The contents of which should look something like this
Code:
# Configuration for builds hosted on linux-armv6l.
# $(1): The file to check
define get-file-size
stat --format "%s" "$(1)" | tr -d '\n'
endef
HOST_SDK_TOOLCHAIN_PREFIX :=
ifneq (,$(strip $(wildcard $(HOST_SDK_TOOLCHAIN_PREFIX)/gcc)))
HOST_CC := $(HOST_SDK_TOOLCHAIN_PREFIX)/gcc
HOST_CXX := $(HOST_SDK_TOOLCHAIN_PREFIX)/g++
HOST_AR := $(HOST_SDK_TOOLCHAIN_PREFIX)/ar
endif # $(HOST_SDK_TOOLCHAIN_PREFIX)/gcc exists
HOST_GLOBAL_CFLAGS += -fPIC
HOST_GLOBAL_CFLAGS += -include $(call select-android-config-h,linux-x86)
HOST_GLOBAL_CFLAGS += -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
HOST_NO_UNDEFINED_LDFLAGS := -Wl,--no-undefined
You can now use the native pi toolchain to build with the aosp sources, at the very least you'll be able to compile the host tools such as fastboot , adb natively on the Pi. Whether you'll want to go about compiling a full android build using the Pi and whether that is even remotely sensible is a discussion for another day! :laugh:

Hey, thanks for your work on this. Sensible or not, it would be pretty cool to run an AOSP or even a CM build on your phone that was compiled on your Pi.
I tried compiling Boot2Gecko for my SGS2 on my Pi as well, but that kept dying about 6 hours into the build .
I got really lost (just learning all this stuff now), but learning it all while building a project you really like would be far more interesting that learning it while building "nano" or "Vim".

fewesttwo said:
Hey, thanks for your work on this. Sensible or not, it would be pretty cool to run an AOSP or even a CM build on your phone that was compiled on your Pi.
I tried compiling Boot2Gecko for my SGS2 on my Pi as well, but that kept dying about 6 hours into the build .
I got really lost (just learning all this stuff now), but learning it all while building a project you really like would be far more interesting that learning it while building "nano" or "Vim".
Click to expand...
Click to collapse
Yes or compile on the Pi for the Pi, If you want to try do that there's the beiginings of the other side, i.e armv6 target files on my github, It actually targets armv5te because that is already present as a valid target in the AOSP build system, a throwback to pre gingerbread and the HTC Dream ( G1 ) etc.
Thinking about it though, The build system may need a little more adding as I think only x86 based cross compilers will be currently selected for target compilation. I'm yet to get my Pi, there's currently a 6 week lead time on them and I'm thinking about holding out for the 512MB version. Until then it's QEmuPi for me!
The Android build system is pretty forgiving and will let you compile things piece-meal which is good because I don't think it would make it all the way to the end in one go no matter how many hours you give it.

Trevd, I asked JBQ on G+ and he said you should contact android-contrib for how to submit your work to be integrated to AOSP. . I'm pretty sure its a mailing list.

AdamOutler said:
Trevd, I asked JBQ on G+ and he said you should contact android-contrib for how to submit your work to be integrated to AOSP. . I'm pretty sure its a mailing list.
Click to expand...
Click to collapse
Indeed, it's at https://groups.google.com/forum/?fromgroups=#!forum/android-contrib

AdamOutler said:
Trevd, I asked JBQ on G+ and he said you should contact android-contrib for how to submit your work to be integrated to AOSP. . I'm pretty sure its a mailing list.
Click to expand...
Click to collapse
Hi Adam, Thanks for that, I never really considered it, Last time I read, which admittedly was a long time ago now, they were a little more averse to submissions from the random punter. Maybe they've soften up, or maybe I've just made the whole thing up in my mind It would look alright on my c.v ( resume to you guys ) . However It's far from ready for that. There's some more tweaks to add to it, maybe commands like "make host" to just build the host platform would make sense on a device with limited resources like the Pi
pulser_g2 said:
Indeed, it's at https://groups.google.com/forum/?fromgroups=#!forum/android-contrib
Click to expand...
Click to collapse
You're the second person to do that to me! Someone drops a "google groups link bomb" on me and I lose an hour of my life reading all the posts, It's like low rent alien abduction! LOL :silly:

AdamOutler said:
Trevd, I asked JBQ on G+ and he said you should contact android-contrib for how to submit your work to be integrated to AOSP. . I'm pretty sure its a mailing list.
Click to expand...
Click to collapse
I was bored waiting for my board so thought I ask if google want an hand, well more of a full arm than just an hand.
Me On Google Groups said:
https://groups.google.com/forum/?fromgroups=#!topic/android-contrib/w5UWtdSTwSg
Hi
I've recently added linux-armv6l to the android build system as a HOST_ARCH so I could build adb natively on the raspberryPi. Is this something you would be interested in adding to the official build system?
Let me first explain why you wouldn't want to accept this.
1. Adam Outler from XDA-developers.com suggested I make this enquiry, Initially, I refrained, given the limited scope of the change I had make which focuses on armv6l specifically and although I would be Interesting to see just how long an AOSP build would take on the RasPi soley from a technical view, I don't think there would be anything to be gained from officially supporting such a device as I made the code publicly available through GitHub.
However upon further consideration this feature can have a much broarder appeal if it was changed to a more general linux-arm HOST_ARCH. Given Arms' current "March" into the server market plus the availability of higher end fast multicore processors such an addition may have a practical real-world application soon then rather than later.
I look forward to hearing your thoughts on this.
Thanks
Click to expand...
Click to collapse
As I pointed out, Arm is getting more desktops now-a-days so they might do this one themselves
[EDIT] Here's the Big Man's Reply
JBQ From AOSP said:
I think we could consider it in principle.
However, I'm not convinced that building all of Android on an ARM host
will be practical any time soon. Because of that, I'd rather avoid
extensive changes much beyond adding HOST_linux-arm.mk. For now, I'll
also want to rely on the distribution's host compiler, to avoid having
to deal with the weight and licensing issues of prebuilt toolchains.
What scope do you have in mind?
BTW, I suggest that you wait until the source release of Android 4.2.
We've been tweaking the build system such that it's easier to control
what gets built, and that might be helpful in your case.
JBQ
Click to expand...
Click to collapse
Looks like a goer then. Because thats the only file I had to add to strart with..

DISCUSSION [hybridROM_MOTOfied] MoTo-nomous v0.1.0 preALPHA, stabile as RC!)

Mods: please, this is a temporary post pending moderator elevated privelege to start forking my build via proper Android Development Section, everything I post is valid and true. No mock ups. Please, do not delete this thread. It is purely education and informational pre-release details to explain down to details most but not all details, as a developer i dont just release security structure or anything deemed sensitive.
A PROJECT UNIQUE AND NEVER BEFORE UNIFIED OR ATTEMPTED SUCCESSFULY. De-Androidinzation and bulding, slipstream and super-enhancing, raising Linux core from the dead to Linux-based and minimally VM until the day comes where I can project it out to substitute it with a replacement, only as good or better performance but not cross-coding as mobility has been so confined to since the start.
Introduction: to a very genetic-autonomous and not even a contender of its class to match it
Hello Fellow co-developers. I am anything but new around here, and I've grown frustrated and impatient trying to revive my XDA credentials I've had auto saved for years and yeasrs. Please, if you find interest in what you see following A PROJECT UNIQUE AND NEVER BEFORE UNIFIED OR ATTEMPTED SUCCESSFULY. this notification, message moderators or seek to at very least a head-start as I cannot even start a thread in the appA PROJECT UNIQUE AND NEVER BEFORE UNIFIED OR ATTEMPTED SUCCESSFULY. ropriate section, due to having to create an account. I've come to a sheer intolerable irritating boredom with Android, and the fact that well, Google and relative developers, and/or mainline toolchain dev's are well, diddling and we see an entire circus from Donut to Lollipop, then when they rollover on 6, and only then...and with nothing that is cheap to meet the proper standard for the hardware it takes to not back-grade your hardware and Android base version 1.6 (DOH'NUT). Yes, such non-sense as SDcard support when the damn things are ready to evolve into the next format. Don't get me, wrong, I'm glad it made the changelog, but still a mock-up and in a developers eyes so much more could have or should be incremented to a more attainable adjustment and even features. But, this post is not about Google, Android, and a lousy slipstreamed Apps2SD knockoff repurposed as adoped storage. I've always tested roms, tweaked, modified and until I found performance, stability, and can go 2 weeks without losing 40 hours of dedication getting it where she needs to be, I started porting per-say, drawing back the resource-loving java base they use in every phone regardless the base, or OS....but I have yet to see anyone shoot for the Linux-Cabal. A tip-the-scale fork of Android where rolling release and as come the updates increment, so shall the independance of too in the Android cocktail for my liking.
Let's just put it out there, I've been stabilizing and unifying a custom build (at this point for Moto ARM), and yes I know waht I am saying but to title it a ROM A PROJECT UNIQUE AND NEVER BEFORE UNIFIED OR ATTEMPTED SUCCESSFULY. would be mislabelling and a blow to what I think the OS deserves. More Linux backbone, compiled and debugged to hell and back step by step. I don't have any plan...YET to play god and cut out any serious concept such as framework, VM, but I have a goal, and a very vast plan drafted for the next quarter. I know any Linux Penguin-Dorks, and developers who know their cards and where I'd bet my bytes in any arena vs most other Os's.
History and Pre-requisuite (in order to enter and initialize a new fork officially, and establish a support system consisting of credible, daily-active and feedback producing beta-testers as well as the system and policies they will adhere to throughout initial first phase. This is not another AOSP or clone of source and hidden bugs you have to come to discover the hard way. I am offering only until another phase anyway, to primarily and MotoG3 ONLY, device dependent. push, shove and patch my tamper-resistant modules will enforce any interopibility. Remeber these are encrypted with MULTI-LAYER mutli-bit and a subset of different combination encryption algorithms and not APK, were weaning that dependence slowly but eventually here. Modules, system core hard up and real time individiual file encryption layering system. Safe from FBI and NSA and Israeli counter-parts. Included but not enforced are optional ability of IPC (Tor-lke) supreme sms, voice chat, and push to talk functionality, and among per file on top entre data drive encrypto....comms will be dual-end encrypted, obviously all of which can be enabled/disabled, configured and tweaked to ones preference.
Until I have proper authority and have enough resonsibility good-boy credits, there will be nothing. And I mean no beta program, no releases, no source code except I will move along to the next accepting Android community, which is my last thought and not at all in my interests. I am a developer 16 years, on a broad number of languages, on many arch's, from pascal, html, basic to visual basic, c, c++ C#, java, to ASM (yes Im old school, an I only dispense above and beyond what I would set as a mile stone.). All my projects in the past, creating the very first OpenGL wrapper, and utilizing a direct-injection loader that was always available in HL.exe. Primarily for Counter-Strike, as Valve global banned any cdkeys and steam accounts associated with at first any Alias nearing the format of my preferred handle. As they rolled out VAC for the first time, I watched every (neraly) system hook based all in one hacks go down as KIA-dead soldiers, while my opengl-wrapper emulated the driver, allowing my to get raw data to maipulate, block, pass-trough to the real-deal OGL.dll. My OpenGL in suspended development and without requirement to play tag with steam and losing 100 purchases of Counter-strike making a VAC-undetected, play for a day or 2 then POOF. Another good key gone up on Joolz, like his sorely lost system hook as it was spitting calls to the Windows API, the HL api, and just many easily noticed flags that his only circumventing was heading on VAC module manipulation, playing with memory in process, unloading and this damn module was live, as in every server change a slipstreamed update could be pushed and suddenly the VAC process, and all the memory offsets surgically and delicately rendered harmless. Too much working hard than the efficient smart ways I came up on. Why try and reinvent the wheel when you know the wheel is superior to date. Kid wasted his entire adolescents, and his family savings trying to serve up something that guarenteed, yes you will be the best hacker online, yes you will be detected by the end of the weekend, and the advantages well, there were none except a trial what hacking a system hook was like. As for my opengl, well at first for Valve, they did their thing wiping out the hundreds of hacks but only 1 or 2 who had stood any sort of equality to the efficacy, stability, virtual impossibilty to detect as I took a native function very seldom known and not documented, and even those who did, none had the brains to probe and go from a function with no instruction or info to the process and how to invoke and follow it through. I didn't reinvent the wheLet's just put it out there, el, but I gave it redbull-wings, titanium belts, nitrogen, and embedded withtin the system from which VAC also called home and well, all its code and dependent libraries, modules and api calls gatehered and had conferences and played golf. VAC could not for years, learn how to attack itself, and this was a fluke at first. Next I started to get out the matches, fire playin time....and i love to push buttons see where or how far i can get.
LONG story short, my very first C++ project, very atypically, was a win32 video card gfx driver, and wrapper and then put Joolz down deep, I was able to hybridize a opengl driver to bear code of no relation at all, not even close whatsoever, and without trying to break and enter a bank and crack a safe while risking setting off an alarm just to steal a 20$ bill. Get what I mean, this was at the age 0f 13. Lost my E-DEV virginity and any dev working in a windows environent, on win 98 knows that for a first project, you don't just self-teach yourself to code then start squatting and pushing out dynamic link libraries like they are ever coded to spec in MS eyes, and its just not a novice coder challenge. The following project, most of your in FTA satellite likely have heard of the latest of a technology innovated on my part and consult with few others on my FTAbins team. Also the author of the handbook aka the bible to the absolute and very well drafted, and at its time prior to increases vastly in bandwidth, it was predecessor and stepping stone for entry to IPTV. Yes Nagra2 was never cracked, it was actually a breach of trade secrets and confidential patented technology on the behalf of a disgruntled and underpaid dev who was a team lead on the the maiden of its release. For the unaware. Nagra2 is the security protecol and encryption system designed to scramble satellite television signals, as far as from my involvement only Dish Network as far as satellite, but also used and more so in europe, australia, uk and asia, on cable boxes (digital) usually those whom took input to your subscription via smart card.
But they double-time develloped and debted themselves over a exploited draft (N2) that really didnt secure a damn thing, only was a deterrant but always 24 hours behind every key roll. NKS is the patented tech, as nagra3 was exponetially much more secure and utilized 5 times the bit depth for each key, and rolled on predefined and update at randomly subscriber only pushed updates. Virtually impossible to crack, but with the aid of more advanced on completely different architechture and embedded firmware nontheless, i wasn't that intelligent i suddenly could learn 5 more instruction sets from x86. But with very little effort, and suceeding with no difficult to overcome blowbacks. Developing not an exploit, but a shadow, if you cant beat em. Join em. and that we did, nothing troubled DN ecm dev's more than trying to circumvent a system that utilized subscriber keys, and encrypted, offshored and live-streamed direct in millseconds behind a authentic event trigger, key roll or key changes and ecm's. ecm's become counter-effective when those you target are identical to your nonIKS subscribers
Thats just some history shared on 2, early on, but also serous and major accomplishments to certify and add credibility to what I claim to do and if doing this at 13 and 15 respectively, both drawing hundreds of thouseands to hundreds of millions from each of 2 entirely different classification corporations. But a thorn in both eyes while dancing circles around them, not even hitting puberty are 2 that only opened channels to knowledge, and expanding my IQ in area's and subjects I would never have thought prior,
I am not ready and urgently tryinHistory and Pre-requisuite g to put something out not prepared to dump unassessed to public, but in context I only initially had prospects of private membership availability and even that I have not authorized either. I am running an XT1540, but kicked alot of Moto framework, slipstreamed Sony framework minus the headache inducing svox, and bits and pieces of certain framework manipulation, but only in areas of absolute necessity.
Minus the not-well supported termux app and api, my build is just as extensive, with a integrated system bin directory containing apt, dpkg, a indirect but priveleged api bridge to all things android and its framework. Wifi-N enabled, 2.4ghz and 5ghz on one that only natively ever offered 2.4 G. Also, some off the books properties, I've been able to extend and further dominate the radio and modem accessibility, more specifically on UMTS/AWS bandf here in Canada on WIND. Now alot is new but I've yet to encounter very many warnings let alone any real conflicts or stability or performance setbacks. CPU is unlocked, can be volted and clocked as well as GPU, and although schedulers are there, much needs my expertise and some fine tuning before I'd even open my mind to considering it in control of fatality-potential software on another persons device.
Now, with apt and a 3 more repos than termux can match. Many would give their left nut just to have even 1/4 of the full capability (and i mean capability of all thats fully stable and operational to perfection as of right now). I had to nearly wrestle my device from a buddy of mines hands, and very promptly vacate his residence as he was dying to just get a particular build of metasploit not freely available to public, and on that part metasploit is integrated discreetly but as building block and one of many that basis the security infrastructure I am still actively forking. Stringray-safe, no prying eyes or cloning cell towers to snoop through anything private.
Currently my personal attention has me fired up towards recompiling Pale Moon custom build, and likely a entirely new browser with FF initial base but this fork of Palemoon is gecko oriented and Android API elevated privelege, it has features that even addons of chrome have yet to scratch. Capable out of the box as a IPC/Tor private browser or entire device firewalled, Tor/IPC and crypto down to the teeth. I have my own fork of recent builds of Adobe flash module, and stagefright is a secured as well. All exploitable lose ends are presently beyond par, as Android hasnt even come to that extent yet.
Anyways, I wrote this just thinking of some of my favourite features. I'll tally a list and re-post this alll in a better edited and spell-checked draft. Yes, i will post screenshots, but ONLY on request. If i have to screenshot otherwise we would all be loading alot of png files needlessly.
Xposed & MOD EDIT: warez reference removed & 3C Pro potential unified hybrid of sorts in consideration too. Pending confirmation. Also, I've been fortunate to be in possession of a Perfect-ADB i nicknamed it as it is a custom build with everything it should have plus some, and finally for right now....TWRP just makes me angry how we have 2 dozen random versions available but each has its own catch, the newer the worse it is it seems. this is unacceptable. too many builds, too many cooks in the kitchen, and off the primary source obviously. like a cocktail of suicide soda. just add 10 flavours, flash it, if it boots slap latest and DISTRIBUTE! unacceptable, this is a development resource credible well established website and name, sigh, but one thing at a time.
i will be remaining on my lonesome adding, pulling and testing my flavours and shiny sparkles with neon colors until the day i can start my devdb. and the day i do that i will immediately open up to members. with consideration of development and vetted testers prior to extensive durability and relibility testing..
Til then, mkocmut1986 @ gmail.com should you require contact.
or PM me. I got my hands full, and im but one dev as you can tell and constantly 100 new innovations to add.

Can you tell this story in short in noob language Not everyone is a developer here.

Sorry @mkocmut That was so long I skipped it... How about a tl;dr version?

@mkocmut: Well I read all the parts, all the history but one question: what was the purpose of writing all this?? BTW, great writing, enjoyed it. And yeah, I would appreciate a few screenshots if you can bother uploading some png files here, thanks.[emoji1] .
Broadcasted from Zeta Reticuli

Says: "LONG story short..."
Goes on to write 11 more paragraphs...
You're a passionate fella, I'll give you that much. Heheh, strangely enough, your post kinda made my day. (-:

A wouldn't mind u posting a link to ur beta port??

mkocmut said:
Introduction: to a very genetic-autonomous and not even a contender of its class to match it
Hello Fellow co-developers. I am anything but new around here, and I've grown frustrated and impatient trying to revive my XDA credentials I've had auto saved for years and yeasrs.
Click to expand...
Click to collapse
Would be interesting if you at least tell us what's your old username.
mkocmut said:
Modules, system core hard up and real time individiual file encryption layering system. Safe from FBI and NSA and Israeli counter-parts.
Click to expand...
Click to collapse
You totally forgot about the KGB...

THREAD CLEANED - Please don't post references to warez/software that violates XDA Rules

Wow! The room is spinning after reading all of that! It's left me with a feeling of huh? But either way I am almost certain that you are very passionate in all the above and I'm cool with that. So preach on brotha!

Good luck man. @mods : if someone quotes the whole OP, burn him!

sounds cool to unlock the cpu + gpu hope all your plans will be made possible

HelpMeruth said:
sounds cool to unlock the cpu + gpu hope all your plans will be made possible
Click to expand...
Click to collapse
How u getting on dev?

Any updates?
Sent from my SM-G900V using XDA Labs

Newyork! said:
Would be interesting if you at least tell us what's your old username.
You totally forgot about the KGB...
Click to expand...
Click to collapse
Late reply, but the KGB has been gone since the last millennium
---------- Post added at 01:02 PM ---------- Previous post was at 12:57 PM ----------
mkocmut said:
Modules, system core hard up and real time individiual file encryption layering system. Safe from FBI and NSA and Israeli counter-parts.
Click to expand...
Click to collapse
Worried about Israeli intelligence? If you're not involved in terrorism, you'll be fine, and if you are, then I'd want the Mossad to have your info.

Sounds more like drunken late night ramble than anything else. Especially since there hasn't been a peep out of him since.
Sent from my MotoG3 using Tapatalk

riggerman0421 said:
Sounds more like drunken late night ramble than anything else. Especially since there hasn't been a peep out of him since.
Sent from my MotoG3 using Tapatalk
Click to expand...
Click to collapse
We can still hope that this will ever be released right?

Sure, why not? Keep the dream alive.
Sent from my MotoG3 using Tapatalk

Hey, Whats up? :laugh: