Related
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
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
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
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:
As seen here
https://www.reddit.com/r/LineageOS/...ect_trebel_devices/?utm_source=reddit-android
LineageOS team state that project treble is in its baby shoes and completely dependant on google to optimize it even more since as of now gsi rom requires certain adjustments for each device, so will project treble successed?
any1 has an insight please share.
I think it needs more adjustment. The kernel should be universal and updateable along with the OS, it's pretty universal as it is at the moment. Drivers should also be standard and updateable, at least for standard items. There should be a driver model where possible to support other devices, and any phone specific changes could be done through manufacturer supplied drivers. There's really no reason why it can't be done, it would be along the lines of how Windows works. Of course, it can be tailored to suit phones.
System updates should realistically come from Google, it would mean all phones and devices would be up to date with the latest security updates. The phone can also check with the manufacturer for specific updates. If Google keeps them apprised of any changes they can update their specific updates in time. This model would mean individual service testing for a new OS update etc wouldn't be a problem since it should at least be compliant with the base model.
Don't forget Google tracks down security leaks in other OS like Windows, which isn't even a direct competitor, and releases the security leak information if it isn't patched within 30? days. How many Android devices are updated with security patches within 30 days by the manufacturer? It's very much a double standard. Google really needs to think of an even more universal model like I just depicted for Android 10 Quinoa Slice (or whatever they call it).
Will Treble succeed? It's a step in the right direction, but needs more work. Not only should something like I just described be done, it should be made mandatory for all new devices. It doesn't mean custom versions are out, but custom versions would have to have OTA updates and be updated quickly along with the standard OS.
To say whether it succeeded or not, I think you'd first need to define what's its goal.
I still don't even know the answer as of today.
Some people say that the goal is to have a system image controlled and updated by Google.
But I don't see this happening any time soon. Google would need to test their GSIs on many devices, and they didn't even test P GSI over O-MR1 Pixels!
It seems to me that their goal was simply to make updates easier to OEMs. Considering Essential PH-1 getting Pie day-one, this might seem a success.
But we'll need to compare Oreo adoption rate to Pie's to confirm.
Oooh someone made a thread so i can moan cheers
The main problem with treble for me is that it's splintered between a plethora of devices, so one dev will release a treble rom and a multitude of device owners will flash it, each with their own subjective problems and issues, requests and wants.
And there lies the problem, it's difficult even when it's a dedicated rom thread for a particular device to get help at times.
So when you have a bunch of users talking about completely different devices you haven't got a hope in hell.
I think there should be branches to each thread for each specific device, that way help threads can be more linear rather than the chaos that it is at the moment.
Least that's my thoughts
My only rom i've flashed is RR and besides a few missing features, Fingerprint, Stereo and NFC i think it's brilliant.