Database Info

Proposal for mod rom versioning

One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.

I do my best
I do my best ... with the "limited space" we're given for Thread Titles on the forum.
~enom~

I support this though I find it unnecessary. The new beginner user will most likely READ atleast the first post of the thread and they will know what the ROM is based off of. The end user will of course know to read the thread before doing any flashing of any kind so organizing mod rom versioning isn't a necessity. It's convienent but not necessary

I support this because it would make ROM catalogs easier to build, which would benefit the whole community.

why not just post what android version the rom is based on in the first post. First post should always hold the most info anyways.

Since this thread hasn't been moved from the Dev section so far.
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?

alritewhadeva said:
The end user will of course know to read the thread before doing any flashing of any kind
Click to expand...
Click to collapse
rofl. Funniest thing i've read all week.

+1
how about shorthand naming such as
for example:
CyanogenMod = CM-AOSP1.6r1-v4.20

If you're talking about cyanogen mod, you might want to add a couple more zeroes at the end. Anyway, I had proposed this too a while ago. I like your format, and I'll go one better; let's do cook-androidVersion-buildVersion-feature.bugfix
for example, the build I made this morning would be "jm-1.6-Donut eng.jubeh.20090930.070211-0.0"
jm is what I use for my builds (short for jubehMod)
1.6 is the current android branch (as per build.prop, no 1.6_r1 yet)
Donut eng.jubeh.20090930.070211 is the build number the compiler assigned to my build, people who work off of modding factory releases or build for dream_open are the ones who usually come up with things like CRC or DRC etc, I build for "AOSP for Dream" (it's a new "vendor" added)
first 0 is feature number, at this point my build is nothing but stock AOSP donut, no Google apps, no a2sd, no netfilter, no compcache, no bfs, just stock donut, so say I were to add a2sd, then I'd go up to 1, as I would have added one or more features (and this would be listed at the change log), basically, anything added that improves the build (and that's not a fix) is a +1 to feature
second 0 is bugfix. For example, right now my build works correctly in every sense, but I have a problem with the video camera where video is of very poor quality (real problem, I'm trying to figure it out), so say i get it fixed, then my bugfix number would go up 1, so basically, anything changed in the build strictly because it didn't work as intended is a bugfix
the last two numbers would be allowed to go past 9, so no more pressures to add .1s at the end like cyanogen was doing to prevent jumping to build # 4.2

karthikjr said:
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
yes just bench mark. its much better than benchmark pi only test the cpu really

by the way, I've been saving pretty much all roms that have been posted here (notable exceptions are haykuro's, jf's, and theduded's roms, I haven't been here THAT long) and I have them all saved on my computer separated by /cook/build/ for the Dream roms and /build/cook/ for the Hero ports. I guess I could run a quick filesystem lister and upload that list for people to see so they can sort of get an idea what mod release corresponds to what build

Here we go, I had to upload it inside a zip because of the stupid 2kb limitation on text files (this is 10kb)

lbcoder said:
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
Click to expand...
Click to collapse
................................

Hi jubeh,
Thanks, this kind of cataloging is exactly why the OP's suggestion will be helpful.

karthikjr said:
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
I'm not so sure that we do...
I think that that should be more of a "details" thing.
Maybe we can go with "name-officialversion-modversion[-custom]" (square braces mean optional). Name might be a good place to keep modelnumber (I assume you mean by that "dream", "magic", "hero", etc.),
i.e.: supercustomrom(DREAM)-1.6r1-0.0.0.0.0.0.0.1-cc_swap_a2sd

new binder driver helps your phone run smoother

Hi guys,
I've written a completely new Android binder driver (for IPC), which is targeted to solve some fundamental issues in the existing driver. One main improvement is to make concurrent IPC calls possible. Some background info can be found in my earlier post on Android kernel group:
http: slash slash groups.google.com/group/android-kernel/browse_thread/thread/c57874670e4decb1
(oops external urls are not allowed for new users
There weren't many people interested due to low volume of the group. Now that I have completed the first version, which is back compatible with the existing driver, and fixed a few bugs. I've tested on the ICS emulator and my phone U8150 Froyo. It seems to be running quite well, but I want to see how it runs on other Android devices while I'm getting my new phone. Test results, bug/issue reports, and of course community comments will be very welcomed, which are important for me to determine how the code should further move on.
Although not proven, I'm expecting not only those dual core phones, but single core ones will get an overall smoother response in various parts of the system.
Okay if this still somehow interests you, you can find my project on github
https: slash slash github.com/rong1129/android-binder-ipc
and just dive into the release directory, use the latest version (0.4 so far) to patch your kernel source tree, then upload the new kernel image to your device and see whether it works for you.
Note this is still an early release and has very limited tests so far. Please make sure you understand the risk before you hack your phone and always back up everything before you started. As other disclaims go, I'm not responsible for any damage may be caused by or related to using or in the process of using the driver
Lastly, happy hacking!
Cheers,
Rong

*subscribing to this thread*
Hi Rong,
thank you so much
our phones, tablets, etc.
can't have too much smoothness
I hope that I'll find some time within the next weeks to also give this a test on the Xoom and see whether it works (with ICS; Team Eos kernel)
there at least seem to be issues with ICS on the SGS (galaxys s1)
http://forum.xda-developers.com/showpost.php?p=23937103&postcount=2502

I found this thread . Is this driver the same on all android devices and roms? Or do you have to mod it for every single device/rom?

A ton of difficult questions about Android

They are all about Android 4.3 and upper.
A pair of questions about unrooting/locking/unlocking/booting.
1) What are the benefits of rooting other than being able to a) set custom cpufrequency policies, b) being able to update your phone (to custom new ROMs like cyanogenmod) when your OEM has decided to stop supporting it, c) full filesystem access, d) tuning sysctl parameters?
I don't like the fact the rooting totally breaks Android's security model.
2) Do I understand correctly that a locked phone is the phone in which you cannot overwrite/replace/customize vmlinuz? or there are even stricter limitations?
3) Do I understand correctly that in order to change e.g. /etc files you don't really need a custom ROM, you can boot into TWRP and replace/edit/remove the needed files?
4) Why does unlock wipe all your data?
5) If the phone is locked, how bootloader/firmware understands that our bootloader is untempered? Does the bootloader have a digital signature? I have this question because let's imagine that I 1) unlock 2) change vmlinuz (allow superuser) 3) lock?
6) How does "oem lock" verifies that system data is genuine? Or it simply wipes everything clean? Does Android has some (RO) partition which always contains a genuine virgin ROM you cannot meddle with?
7) If I do "unlock" on my Nexus device, without changing anything or installing any 3d party bootloader (like TWRP), will I be able to update to new official ROMs via OTA updates?
8) Why every "lock" manual says that I need to upload a genuine official ROM - what if I've changed it and made it "rooted"?
Storage.
Why does Android has so many partitions?
What method is used to break the internal storage into partitions? Is it some kind of partition table (MS-DOS, GPT) or it's hardware based?

1. The purpose of rooting is to give you an access level equal to the product's development team. Rooting is basically an unofficial way of doing exactly what the developers are doing on a daily basis. You can either consider that people are going to root and that the community adds value and bug fixes to your product by independent development (Android); or you can actively take measures to lock down root access and maintain a a gateway to development in the belief that this doctrine maintains a unified experience, protects security of intellectual material, and provides better overall security (Apple).
There's pros and cons to each side. With the Android thought, you are offloading a lot of your development burden onto the community and getting R&D, patches, and extending product life in return - for free. You take the risk of lowered security, but usually make it back because the community is a larger workforce with greater man hours and a vested interest in the product. They provide you with answers to problems you don't even know about as long as you listen.
With the Apple thought, you maintain a strong control on making the product do exactly what you want. This makes the product work exactly as expected, which can be easier for the user. However, your design has to be VERY good for the community to accept it. You also suffer in that you lock the community out from enhancing your product, so you HAVE to be the one coming up with all the ideas. Also, if the community finds a breach in your security, it can be devastating. Look at how much energy and money Apple pours into preventing jailbreaks.
I wouldn't be too worried about the 'break in security model' as you say, unless the Android platform becomes fraught with virii. After all, consider that unix on your PC is essentially the same thing, and you request root access on it to install certain things.
2. I'll let someone else chime in with a better answer
3. with root access you don't need a custom ROM, you just need the ability to access root permission and a file browser that will get you to protected areas.
4. I'm not sure I'm thinking about the same stuff as you here. Rooting doesn't wipe anything from what I remember. Replacing the ROM does, but that's because the ROM 'installer' doesn't have anything to preserve user settings. I don't consider this weird since Windows didn't have a really decent migration package built into the installer until windows 8.
5. There's a counter that iterates. Research trianglemod for an example of this topic.
6. It's hard to say what the OEM has for tools without them releasing the tools to the public. They, of course, are going to have better tools than us. No, there is no read only partition that I'm aware of that contains a full ROM that you can dump back in place. I've gone so far as to fully wipe my Galaxy S3 to the point where it only had clockworkmod and a boot screen that never went away. If I went much further, I could probably brick the phone, requiring an external programming program. A full brick would remove interface to your PC, which I believe is a possibility.
7. A new OEM ROM update will do one of three things:
a. update the phone to the new ROM and most likely break all the apps
b. update the phone and wipe everything
c. partially update the phone to a state where it won't boot due to a corruption (I've been here, lol)
8. not sure what we are talking about here
9. Android is based on linux. Linux is designed with specific partitions to handle different tasks for storage, memory access, stuff like that. If you aren't happy with the design, you are free to do something else - you don't have to use Android on an Android phone, you can probably put FreeBSD or Slackware or something, or write your own kernel.

ROM and kernel flashing guide for beginners

XDA Kernel and ROM flashing beginners guide.
If you are reading this, you’ve found your way to the famous XDA Forums. The place where developers and users contribute to the spirit of open source Android development.
If you already have TWRP setup and running and just look for the next ROM to flash, this guide isn’t for you. If you wonder what this TWRP thingy is or what exactly the three letters, R O M mean, that float around these forums all the time, then read on.
This paragraph is about the basic geek terminology, used by developers. ROM stands for read only memory, which basically is the system partition of your device, which can only be read, not written. In everyday usage scenarios, where you browse the web, download some apps, or chat und Telegram, you will never get in the situation, where you have to write on your /system partition. If you plan to get your hands on one of those amazing custom ROMs, that add battery life, performance and beauty of use to your OS experience, the ROM is the smartest way of accomplishing this goal.
What a custom recovery is used for:
This is where the recovery comes into play. The recovery partition is pre installed by the manufacturer of your device. It is used for OEM software updates, wiping your cache and dalvic or performing a factory reset. Enough functionality for the average Joe, but this is XDA developers. Things get interesting, once you unlock the full potential of your device. To do so, you’ll need a custom recovery. Team Win Recovery Project (TWRP) is most common these days. It is fully optimized for touch screen input and offers various features, that even come in handy, if you don’t want to modify your phones software. Nandroids for example.
This is where things start to become really interesting. There are various recognized XDA Developers like Francisco Franco or Flar2 who focus their efforts on bringing custom Kernels to their supported devices. What is a kernel? Do I even need it and why should I bother changing it?
To say this clearly, the kernel is the heart of your software. You might use your phone with a broken Bluetooth driver, without caring to much, without a kernel installed your device won’t be able to boot. So what does the kernel do, if it is so essential for a proper working phone? We can describe it as the bridge between hardware and software. That latest processor and the wickedly fast RAM won’t do anything without something telling it how to unleash it ‘s potential.
That’s where the kernel comes into play. You can imagine the kernel as a moderator between the hardware and the software of your system. An example: You touch the screen to launch your favorite game on your Droid. This game is really challenging your hardware, so the processor has to run on a high clock frequency, otherwise the game would take ages to load. The kernel detects your input and ramps up the frequency by it’s in input boost driver. This is often a pre configured value, that is used as soon as some (touch) input is detected, that’s why it is often called touchboost. OEMs choose a middle frequency offering a good balance between power consumption and performance.
For our gaming scenario this isn’t enough, we need the full potential of the CPU and the GPU should get busy rendering all those pixels as soon as possible. This task is accomplished by the kernel. It is balancing the system frequency based on the load of the system, but that’s just an easy to explain example of what a kernel does. The kernel is doing a lot more things on your device. How should the phone know, how much RAM it can give to that messaging application you open every each five minutes? Simple answer, it doesn’t the hardware of your phone is just silicon ready to do your work. You can compare it to a young guy doing an internship at a company. The guy has some potential, but he gets lost in a moment, if there is nobody showing him what to do. This is where the kernel comes into play again. It calculates which task requires which amount of memory and decides, which task should be kicked out of your recent access and memory and, which is there to stay. The messaging application I just mentioned a few lines back for example should remain in memory. You use it all the time, so it doesn’t make any sense to generate some unnecessary CPU load, which eats up your battery in the long run.
As you can see the kernel is more than a boring piece of code. It basically drives your phone, so you really want a stable kernel.
Which different kernel development approaches exist?
There are various recognized developers who focus on UX features. This means they take the official stock kernel (be it a OEM or let’s say the one made by Lineage) and they add their features on top. For example a fading notification LED or a backlight dimmer, that allows to lower the minimum screen brightness further than the stock kernel allows.
These features focus on adding userspace features on top, which don’t touch the core functionality of the kernel, like CPU scaling or RAM management. These kernels are chosen by users who want additional kernel functionality without leaving the stability of the stock ROM in favor of a custom ROM.
On the other hand their are developers and users who want bleeding edge functionality, which brings new stuff to the table, but is to new and not deemed stable enough to be used in the mainline OEM kernel. A good example for such a feature is f2fs support. F2fs is a file system developed by Samsung. It’s main focus is to suite flash storage (like the SD cards in our smartphones), in terms of write speeds it is significantly faster, than the established and rock stable standard ext4. But it comes with certain downsides for example a ROM won’t boot with a data partition formatted to f2fs if the kernel doesn’t have the required f2fs commits. A year back their also were some major issues with root, which made a lot of users switch back to the stable ext4. However if you want to squeeze the last bit of performance out of your phone, the kernel is the way to go.
Kernel tweaking: A custom kernel allows you to modify certain parameters, which aren’t accessible for the using an official kernel. Some developers ship with their own app, which is optimized to tweak their own kernel. This ensures maximum compatibility, one of the reasons why those kernels are so successful across all XDA sub forums. You don’t have to use a kernel managing app to modify your kernel configuration, you could also use an init.d script, but this requires further knowledge. No matter how advanced your knowledge is, it doesn’t get any easier than using an application to set up the configuration of your choice.
Kernel tweaking fills another guide and their is already a really good one, that you should check it out. Further links will be put at the end of this guide.
To root or not to root?
Another controversial topic is rooting. While a lot of OEMs try to prevent you from doing so by locking the bootloader, a lot of enthusiast swear on the power root access unleashes. Often android root is compared to administrator privileges under Windows. This is an illustrative explanation, but isn’t accurate. Root goes far beyond what Windows Admin rights allow. The main difference that jumps right into your eye: Microsoft allows Administrator access out of the box. Root is blocked by all OEMs, you have to enable it manually (by flashing a root solution of your choice. More about popular root solutions and their main advantages and disadvantages down below.
So what does root do? It gives you full control over your device. One of the main advantages is to gain write access to your system partition, which normally is read only. The power of root is defined by the knowledge of the user, the more you know, the more you can make out of it. For beginnners root apps like Titanium Backup, Adaway, Better Battery Stats or SD Maid are interesting. They utilize the potential of root for you without having to dig to deep into the topic. However root isn’t enabled by default for a reason. Most big custom ROMs, don’t ship with root out of the box anymore these days. Back in the day root basically just gave you more control, without any major disadvantages. This however changed with the introduction of Safety net by Google.
The company developing the OS we all love, is trying to make Android safer and they are pushing this approach forward these days. If you just flash SuperSu, Safetynet gets triggered which results in being unable to use apps which use Safetynet to verify the integrity of your system. Mainly banking apps, but also Snapchat for example or that stupid game, that generated all the hype in summer 2016. You got curious about root or came to this forum, to figure out how to root your phone? Then the next paragraph deserves your attention.
Most XDA users used SuperSU developed by XDA legend Chainfire during the last years. A while ago Magisk by XDA Recognized Developer and contributor Topjonwu. It became very popular, when Safetynet started to break certain Apps. It allows to hide root from safetynet, but it includes much more. One of the key features is mounting modules systemlessly to your boot partition, that way your /system stays untouched and removing a certain module, doesn’t require more than disabling it and rebooting. What about the disadvantages of magisk? It isn’t as compatible as SuperSU, since that root solution was the standard for years. All the developer arranged their work around SuperSU, but most famous root apps, have already adopted to Magisk, so you won’t run into issues unless you are using really outdated apps, which is never a good idea.
Which one to choose is a decision you can make. Both work flawless and it really comes down to personal preference.
Since nobody is willing to read through 50 pages, I’ll just thank you for your attention. This Guide is on going WIP, so if there is anything you’d like to see being added, feel free to let me know, but make sure to tag me, otherwise I might miss your message in the storm of ongoing notifications. Have a great day and keep flashing.

Helping an old-timer

Hi.
As you can see from my profile, I've been a forum member since the days of O2 XDA devices (2007) and I used to flash other folk's home-baked ROMs often to improve the handsets and remove bloatware. As Android improved I found less need to muck about with what the manufacturers provided and my skills, no longer being used, became rusty.
Enough backstory though, I'm here today because I have a need to find a solution that is affecting the handsets we use in my company, and I suspect that flashing a custom ROM may be the solution.
I work for a small company who operate care homes. We use an app to record our notes, actions, medication administration etc. The app is on a 'ruggedised' android smartphone, with a remote management platform looking after our interests by locking down most of the phone's functions. I adminster this platform and manage the handsets and the software we use.
The problem we're experiencing, is that the handsets keep getting 'factory reset'. We're not sure if this is happening maliciously, or is the result of some kind of software incompatability. Disabling the factory reset option in the Android settings doesn't provide enough protection as the handsets can still be 'hard-reset' using the power+vol key combo.
The two handsets we use are:-
Wheatek BV6300
Oukitel WP5
Neither manufacturer is listed on the forum, so I'm hoping they are other devices that have been rebranded.
Questions.
How do I find out if any of the ROMs on the foum are compatible?
If they aren't compatible, how do I go about sourcing a custom ROM?
Any other suggestions/advice greatly appreciated.
TIA

Maybe limit devices to only vetted employees.
and/or
Pen/paper records then transcribed.