In due for our major rollout event, ARM. Project will be coming to your mako. We are an non-profit organisation alike cyanogenmod, but only focusing on creating a global aftermarket kernel for the Android OS, specifically to remove the major setbacks of linux.
What's so awesome about the kernel apart from stock manufactured vanilla kernels?
- this includes custom codes which are open-sourced, which aims to tweak the linux kernel to the peak for Android. This gives you a feeling like having Android and, at the same time, feel like you have the smoothness like ChromeOS.
What's in the codes you add?
- they are just codes ported over from other lightweight open-source OS, but, will also include our own various inspirations.
Currently, we are in closed development for mako. We are in need of 2 Maintainers for source building and basic bugfixes and 2 testers for alpha testing. Please PM me to discuss on.
We hope to help shape your phone's future!
nicholaschw said:
In due for our major rollout event, ARM. Project will be coming to your mako. We are an non-profit organisation alike cyanogenmod, but only focusing on creating a global aftermarket kernel for the Android OS, specifically to remove the major setbacks of linux.
What's so awesome about the kernel apart from stock manufactured vanilla kernels?
- this includes custom codes which are open-sourced, which aims to tweak the linux kernel to the peak for Android. This gives you a feeling like having Android and, at the same time, feel like you have the smoothness like ChromeOS.
What's in the codes you add?
- they are just codes ported over from other lightweight open-source OS, but, will also include our own various inspirations.
Currently, we are in closed development for mako. We are in need of 2 Maintainers for source building and basic bugfixes and 2 testers for alpha testing. Please PM me to discuss on.
We hope to help shape your phone's future!
Click to expand...
Click to collapse
Can't wait to see how this turns out
Let's just say the release is near!
First few versions will not include features as it will be more of a build clean fix.
Features will come in time by time.
DO NOT report bugs in the development thread. Report it here with the following info:
- Logcat
- dmesg
- A brief description of what happened.
Related
This guide tries to explain very briefly the different types of CyanogenMod builds, particularly for the Sony Xperia devices, and what usage each type may be suitable for. The guide is oriented towards newcomers, who often find themselves wondering what are the differences between these various builds (don't worry, I used to be perplexed myself) and which one would serve them better. Anyone seeking further information is well advised to check the CyanogenMod wiki or search around the forums here.
The nightlies are regular automatic builds* of the CM source. Because changes get constantly pushed to the CM source from various developers, these builds reflect a more or less random state of the code, and because there's no human intervention in deciding whether to build or not, the nightlies can contain random bugs. Actually, the larger and most severe bugs are typically filtered out by the preliminary testing and review process before they even get committed, but it's impossible to catch everything that way. Indeed, the nightlies' primary purpose is just to make sure that the code still builds correctly. Nevertheless, they are also a rather useful tool for large-scale testing -- and that's how these not-so-huge bugs get caught as well.
The more substantial changes or the ones that could possibly break a lot of things (or few things really bad) get tested separately, with the experimental builds, before they are committed to the CM source.
The stable builds are based on a snapshot of the source code that is deemed suitable enough for everyday use. They are expected to be free of any serious bugs. By the way, a "snapshot" is just what it sounds like: a momentary picture of the code at some specific point of time, as decided by of the developer(s) who oversee the project development. In technical terms, the snapshot is a Git tag.
When a stable release is planned, the commits are gradually restricted to only the ones that fix things; the ones that "merely" introduce new functionality (which potentially means new bugs) are postponed until after the release (in developer terms, the code is "frozen"). In this process, the code gets several preliminary snapshots, namely, the release candidates (or RC), which reflect the advancements in the code stabilization and bug fixing. In other words, each new RC should have more and more of the identified issues ironed out, until all of them eventually get fixed, at which point the stable version is finally released (hence why an RC is just a "candidate").
The FXP builds are manual builds of the CM code with patches by the FreeXperia project. FreeXperia is the core group of developers who, with the help from other skilled developers from XDA and CM, maintain the Sony Xperia line of devices for CyanogenMod. This means that (an often asked question) most of these patches get promptly committed to the general CM source. The only exception might be changes that turned out to behave badly. In other words, any fixes or new features in the FXP builds very soon get included in the CM nightlies as well. Unlike the CM nightlies, however, the FXP builds are manual, so they are expected to be more stable: whether because the current code has been confirmed as stable enough, or because particularly problematic one has been patched. Thus, they might be considered the equivalent of the CM milestone (or M) releases.
IMPORTANT: Whichever type of build you choose, always keep current enough backups, preferably of different types (e.g. a nandroid/CWM/TWRP and a Titanium/etc. one) and in different physical locations (in particular, keeping your backups only on your SD card is asking for trouble). Keeping several chronological versions is a wise practice as well (you might, for instance, find your last and only backup to be corrupt). Remember that you can never have too many backups!
Which version should I use if I...
TBA
This guide started as a post in another thread, and I'd like to thank @tilal6991 for confirming what had been only assumptions then. All your recommendations, whether to fix mistakes or to enhance the guide, or even just comments, will of course be very welcome.
----
*) The current list of the automatically built targets, together with the frequency of the builds, is here.
Changelog
----------------
12 Sep 2013 - Initial version.
Note to the mods: I'm afraid I couldn't think of better forum for this short guide. It is relevant to more than just the Xperia T, yet perhaps not that helpful beyond the Sony devices, as the major source of confusion seems to be the FXP builds (and these, of course, are Sony specific). If you do have a better idea, please don't hesitate to move the thread -- and thanks a lot in advance.
Note about "Which version should I use if I...": I'll try to fill that one in as soon as possible, but I got some serious problems at home, so it may actually take a while. Sorry about that.
Guide moved to general...
Nice guide Btw
Sent from mALL GLORY TO THE HYPNOTOAD!!
Dear Developers of AOKP,
first of all: Thank you so much for this awesome ROM which I am using since 3 years by now! Since security has been in the media periodically for quite some time now, I feel like this is the right time to ask: Would you please harden AOKP to include the very latest security enhancements? What bothers me in particular is that it seems even though so much development is being done, vulnerabilities like Mempodroid still seem to be present in the latest builds (using AOKP 4.4.2 for M7UL). A good way to check this is to use the X-RAY Security Scanner. Please fix these vulnerabilities.
Furthermore, would you please implement a feature to toggle hardening like triggered with the app SecDroid? This neat little project unfortunately has been abandoned, but yet the idea should be clear. The developer of SecDroid also released a Guide on how to harden Android. Maybe AOKP can use the Source of SecDroid somehow?
For me, AOKP always will be the best ROM out there. I can proudly say that having donated to the project makes me feel great and I'm looking foward to see AOKP implementing the latest and greatest security enhancements out there. Thank you ahead!
SecUpwN said:
Dear Developers of AOKP,
first of all: Thank you so much for this awesome ROM which I am using since 3 years by now! Since security has been in the media periodically for quite some time now, I feel like this is the right time to ask: Would you please harden AOKP to include the very latest security enhancements? What bothers me in particular is that it seems even though so much development is being done, vulnerabilities like Mempodroid still seem to be present in the latest builds (using AOKP 4.4.2 for M7UL). A good way to check this is to use the X-RAY Security Scanner. Please fix these vulnerabilities.
Furthermore, would you please implement a feature to toggle hardening like triggered with the app SecDroid? This neat little project unfortunately has been abandoned, but yet the idea should be clear. The developer of SecDroid also released a Guide on how to harden Android. Maybe AOKP can use the Source of SecDroid somehow?
For me, AOKP always will be the best ROM out there. I can proudly say that having donated to the project makes me feel great and I'm looking foward to see AOKP implementing the latest and greatest security enhancements out there. Thank you ahead!
Click to expand...
Click to collapse
A few of us are interested in this and we'll see what can be done
BytecodeMe said:
A few of us are interested in this and we'll see what can be done
Click to expand...
Click to collapse
Awesome! What are you planning to do?
SecUpwN said:
Dear Developers of AOKP,
first of all: Thank you so much for this awesome ROM which I am using since 3 years by now! Since security has been in the media periodically for quite some time now, I feel like this is the right time to ask: Would you please harden AOKP to include the very latest security enhancements? What bothers me in particular is that it seems even though so much development is being done, vulnerabilities like Mempodroid still seem to be present in the latest builds (using AOKP 4.4.2 for M7UL). A good way to check this is to use the X-RAY Security Scanner. Please fix these vulnerabilities.
Furthermore, would you please implement a feature to toggle hardening like triggered with the app SecDroid? This neat little project unfortunately has been abandoned, but yet the idea should be clear. The developer of SecDroid also released a Guide on how to harden Android. Maybe AOKP can use the Source of SecDroid somehow?
For me, AOKP always will be the best ROM out there. I can proudly say that having donated to the project makes me feel great and I'm looking foward to see AOKP implementing the latest and greatest security enhancements out there. Thank you ahead!
Click to expand...
Click to collapse
Even if every vulnerability fix was included in source, (for now) it will still not be secured. Unless you compile your own builds with a different platform key, your builds will not be secure. This applies to nearly every AOSP-based custom ROM.
We've talked about it, and we might implement something for milestone releases. But security is a huge huge problem to take on with custom ROMs and there are a lot of heads to the dragon to take down
Sent from my HTC One using Tapatalk
Romanbb said:
We've talked about it, and we might implement something for milestone releases. But security is a huge huge problem to take on with custom ROMs and there are a lot of heads to the dragon to take down.
Click to expand...
Click to collapse
True point. But I'm sure that folks who can add unicorn sparkles to a ROM will even discover and implement some really cool security enhancements & fixes for the already known vulnerabilities. After all, this is a suggestion and to be seen without pressure. Waiting for your next awesome release for M7UL, @Romanbb! You're doing a great job!
SecUpwN said:
True point. But I'm sure that folks who can add unicorn sparkles to a ROM will even discover and implement some really cool security enhancements & fixes for vulnerabilities. After all, this is a suggestion and to be seen without pressure. Waiting for your next awesome release for M7UL, @Romanbb!
Click to expand...
Click to collapse
For sure. I'm definitely not against security enhancements by any measure.
Why isn't it possible to create a tool that can repackage ROMs with custom keys, say, using a Windows computer or Xposed Framework?
Also, isn't Mempodroid what allows us to give apps SU permission?
pan.droid said:
Also, isn't Mempodroid what allows us to give apps SU permission?
Click to expand...
Click to collapse
No. Mempodroid is an EXPLOIT and a vulnerability, please don't mistaken it with SuperSU.
SecUpwN said:
please don't mistaken it with SuperSU.
Click to expand...
Click to collapse
Okay. Just so long as you don't *mistake* 'SU' with SuperSU=)
AOKP Kitkat Rom
The Android Open Kang Project (AOKP) team has released nightly builds for a number of Android running device which bring Android 4.4.2 KitKat update for these devices. One such build is also available for Sony Xperia Z, which runs Android 4.3 Jelly Bean.
gteknet said:
The Android Open Kang Project (AOKP) team has released nightly builds for a number of Android running device which bring Android 4.4.2 KitKat update for these devices.
Click to expand...
Click to collapse
As you might have guessed, AOKP runs through all my veins. I'd probebly never use anything else, if not forced to. As soon as a new nightly is out, I'm using it. But what exactly is the AOKP team doing to make their build more secure?
One of the features that I'd LOVE to have would be encrypted calls between AOKP builds without having to be online or installing additional software. Would such be possible somehow?
Thread cleaned
I suggest several members use the ignore user option if they want to remain members on XDA
I will be keeping an eye on posting. Cut out the infantile crap or you will be removed
This is a development site, take your garbage to a social media site
Senior Moderator
@kennyglass123, thanks for cleaning it up. I really appreciate your effort. Unfortunately though, no member of the AOKP team has answered my initial question yet. Could someone please do so?
SecUpwN said:
As you might have guessed, AOKP runs through all my veins. I'd probebly never use anything else, if not forced to. As soon as a new nightly is out, I'm using it. But what exactly is the AOKP team doing to make their build more secure?
Click to expand...
Click to collapse
Sadly, this question is still open. Since I'm using M7 (Gerneric GSM), maybe @Whitehawkx can answer this?
Yes, we are happy to share our rationale. Recently, we received requests from users and community members, some of which signed a Change.org petition to support Project Treble on the OnePlus 5 and OnePlus 5T. Project Treble is a really exciting technology, but it is not the right fit for us now. I assure you we’re still updating our devices and will continue to deliver high-quality, stable software updates. That being said, we always welcome feedback, and I want to further shed some light on why we are not implementing Project Treble on these devices.
Project Treble requires a storage partition, by which the Android framework and vendor image are separated. However, because partitions were not required of Android N and previous versions of Android, all of our current devices do not feature a partition. According to our tests, if we were to modify the partition layout via OTA there is a risk that devices will brick during the partitioning. We feel this poses too great a risk for our community of users, which is why we have decided not to implement Project Treble on current OnePlus devices.
While Project Treble can increase the rate of Android OS updates, it mainly accelerates the Android framework updates. We were one of the first manufacturers to release an update to Android O. Our software team is committed to delivering high-quality and stable major OS upgrades, and we will continue to look for ways to improve the quality and rate at which we deliver software updates in the future. That being said, we look forward to the future of Project Treble, and how it will evolve to better support devices ahead.
Source : https://forums.oneplus.net/threads/join-our-oneplus-5t-ama-now.686679/page-41#post-17271933
? Share your opinions! ?
It could be a option to provide the tools to make the needed partition once the device is old enough. Say for the OP3. With a big warning that usage is on your own risk. Just like some vendors do when unlocking the bootloader.
I think that would make Al lot of us happy.
GeminiRx said:
It could be a option to provide the tools to make the needed partition once the device is old enough. Say for the OP3. With a big warning that usage is on your own risk. Just like some vendors do when unlocking the bootloader.
I think that would make Al lot of us happy.
Click to expand...
Click to collapse
Too much risk of bricking
Sony Mobile is committed to supporting the open developer community, and one way to show this is by publishing parts of our code as well as selected tools developed by our internal developers.
For some of the Xperia™ devices, we provide Android™ Open Source Project (AOSP) device configurations on GitHub. This means that the software will be open for you as a developer to use and contribute to. This is a way for us to support the open Android community, and it is also a tool for us to facilitate and verify contributions to AOSP.
If you want to build AOSP for your unlocked Xperia device, you find all the resources you need in the sections below.
https://developer.sony.com/develop/open-devices/
Unified 4.4 kernel sources
https://github.com/sonyxperiadev/kernel
Project git
https://github.com/sonyxperiadev/
Bug tracker
https://github.com/sonyxperiadev/bug_tracker/issues
Now you can build the latest Android with the latest 4.4 kernel
Vendor v11 is out
https://developer.sony.com/develop/open-devices/latest-updates
For user security dm-verity and File Based Encryption are enabled by default
Please disable them only if you are developing new features
Regards
J
Why do you deny us full functionality on AOSP?
You claim to support the development of AOSP and Androids ecosystems, but deny us full functionality of our hardware if we switch from Sony stock rooms ?, photos get crazy, lowlight even worse, the volume of sound is completely erased and all post-processing disabled got my XZ as a replacement phone when my newly purchased 9 died, and I have never seen such an openly "supported" project, which has been so denied by developers. There is no person who thinks "it'll will be really fun to develop on this phone, they will take away 90% of their PR sales points just if i unlock it, god what challenge this will be" ... Never happened .. Stop locking features behind DRM and / or make it irrelevant to AOSP ... Snälla... Låt oss välja själva, voiding warranty for UB'ing is enough. Don't remove points that made the phone sell if you really want us to be intrigued to develop, it's too late for XZ now, but for your future flagship, this is IMO a must
And gpu performance on AOSP is a letdown, even with latest v11 vendor files
All build guides are updated with the Security updates
https://developer.sony.com/develop/open-devices/guides/aosp-build-instructions/
Here is the list of all known bugs. If you find bugs you can always open a ticket in the bug tracker and we will check it ASAP.
https://github.com/sonyxperiadev/bug_tracker/issues
In particular, I want to port Omnirom 4.4 to a device which has sources for that particular device available from it's manufacturer's website. Note: the documentation available from the github repo is very sparse and underwritten, particularly in the area of porting and building that port.
4.4 dates back to when I was still active (FYI I have not been active in the development community for 3+ years, kind if just popped in to check things out)
In general, a branch THAT old will not have any support and you likely won't find anyone bothering to code review any submissions. I'm not sure what the current state of the instructions for building for supported devices is.
No project has EVER had significant documentation on porting, because every device is different and the barriers you run into are different every time... It's something that is incredibly time consuming and you learn by doing. It requires general analysis and diagnostics/troubleshooting/problem solving skills. If there were a way to write a step-by-step porting guide - you would see far more devices supported at far higher levels of quality than what you actually see.
What device is this? I'm really surprised that you've found complete AOSP sources from the manufacturer. That's basically unheard of for anything other than Google devices and Sony's AOSP project. If you've merely found a kernel source code drop - congratulations, you've got around 1% of what you need.