FroydVillain 1.3/2.x roadmap
EDIT: Due to unforeseen issues rapidly accelerating the release of 1.3 (more framework changes), I'll edit this roadmap to reflect 1.4 as well as what we hope to accomplish depending on how many of the 1.3 promised features make it into the accelerated release. Thanks for your patience.
Now that FroydVillain 1.2.x is somewhat stable we can concentrate on the next releases.
First, any and all "WHENNNNNNNNNNN???????!!!!!111oneeleven" posts will be ignored. As usual, "when" = "when it's done".
Features/items in this roadmap are things you can definitely look forward to unless otherwise stated, ie, something happens that renders that feature impossible. Like an asteroid hitting my house, for example.
First, the preliminary work.
I promised the guys over at Cyanogenmod that my new build profile for the Hero (and other MSM7xxA based phones, so the Dream, Slide, G1, etc etc) will be tidied up and offered up in a pull request. I will be cleaning up my tree and submitting my changes before I begin work on the next release of FroydVillain. The main reason for this being, the closer the CM tree is to my tree, the less work involved in keeping the FroydVillain tree up to date with upstream fixes.
Right, so the changes.
Version 1.3.x:
Obviously it is customary to break some **** with each major revision just to give me an excuse to release another release after that broken release.
So for 1.3.0 I nominate, umm...nah I'll let you find out. A release post isn't complete without at least 20 posts asking if anyone is having xxxxx problem and a further 20 posts complaining about the said problem after I post that we're aware and we're very sorry and those responsible shall be flogged.
FroydVillain 1.3.x:
Further changes to the build base and source code to move Froyo-on-Hero further away from reliance upon Eclair libraries. We aim to be building a native libcamera.so in the same vein as the D/S guys are. This combined with already eliminating proprietary liblights makes it easier to...
Switch over to the Froyo prelink map. If you don't know what prelinking is, don't ask. Either don't worry about it or do some Googling. The upshot for you the end user should be better stability and maybe even some added performance improvements.
Along with the addition of the CPU profile to the CM base I'm hoping to get VFP support fixed in the kernel and in the dalvik source. VFP is your phone's ability to offload number crunching to a dedicated number crunch piece of hardware. The cpu the Hero has supports it, however support for VFP on ArmV6 architecture is a bit...well, pants. Accomplishing this should also give another measurable boost in dalvik performance since currently the only enhancement to dalvik, is the optimised binary, the source itself still trudges along with only armv5te support which again rather pants.
Giant /data partition. Thanks Maxisma and co. I'm not going to bring this in until we next need to do a wipe, ie, 1.3 since it resizes the mtd partitions. Coupled with old school apps2sd there should never be a single whine about space on /data ever again. Even dkelley could fit all of his dalvik cache data on it with his encyclopaedic collection of apps. Be aware this will be accompanied by an updated recovery.img so the different layout is supported. You have been warned.
Debugged Exchange support. I can't promise that this will appear in a 1.2.x update but I will get it in for 1.3. I don't use Exchange and so have to rely on others to help find the cause of the issue, debug it and test it. I can't believe after nearly 10 years dodging it, I'm back troubleshooting Exchange bollocks again.
Theme revival. Because Google were kind enough to provide no theming engine what so f**king ever (cheers lads) theming is a pain in the behind that involves hacking the framework. However because we now build from source rather than trying to crowbar bits in and out of a prebuilt HTC tree, it's significantly easier to produce themes from the newly built source tree. I'm working with Alex24 on a project to go with 1.3.x which will put Themes back into the OTA app and they'll be available at the same time as the new releases are. This also allows us to easily add more themes over time.
CMSettings/CMParts. After having a chat with the folks at Cyanogenmod they're more than happy for me to make the menu entry in settings feel more at home within FroydVillain instead of looking like a kicking and screaming rip off from the Cyanogenmod ROM itself. So those of you that have been hopping up and down for CMSettings functionality, it's coming.
Better GPS functionality/better radio functionality overall. For various reasons, changes made by Google, the fact we'll never have official "Froyo supporting" radios, bugs creep into the OS when it comes to using newer Google based apps that make use of the radio. We'll have some fixes for the slow GPS locking and the random reboot/crash when looking for a GPS signal. We're hoping we have mobile data+gps properly nailed down as well.
We're also going to look into different Gallery implementations. Gallery 3D is annoying as hell and the bugs with it are likely due to us relying on the Eclair GL libs. So no further ground is likely to be made until/if/when another MSM7xxA class phone gets Froyo which if any will likely be the Legend. That's a big if though. Imagine if you will, 50 metre tall letters I and F, draped in neon coating with a flashing, strobing sign above them announcing "THIS IS A BIG IF." But no whining if the best you get is the old 2D Gallery as I'm really struggling to find any decent Gallery implementation. Which is somewhat surprising. Perhaps we should offer a bounty for a new decent one.
Add further language support
That's all for 1.3.x for now I think. I'll update this as new things occur or as things appear to be impossible.
FroydVillain 2.x:
Kernel 2.6.34.
What? That's not enough? Wtf is wrong with you? Ok fine.
2.6.34 will provide official support for the newer Froyd features such as in built Tethering and no more annoying bull**** surrounding connecting a simple USB phone to a simple USB port on a simple Windows system. Apparently the Windows driver stack is easier to confuse than a 90 year old Alzheimers suffering dementia patient.
We'll also be looking to bring the Hero Froyo platform closer in line to the more complete Cyanogenmod D/S platform. There's really no reason why we shouldn't be able to especially once 2.6.34 is available since as far as the hardware is concerned the phones are practically identical.
More will be added to the 2.x branch as we discover it. Don't be surprised if in the course of working on 1.3.x some features get pushed back to the 2.x release due to practical limitations or it just making more sense.
Now is the time for feature requests from you the user. 1.2.x is now critical bugs only, I do not want to have to make you wipe/flash 1.2.x now until 1.3 hits so any fixes involving a framework rebuild won't appear until 2.x. 1.2.x is now considered feature complete in the scope of features we want to have supported. New features will appear in 1.3.x or 2.x depending on the work required to make them appear.
So the forum is now yours, dear users, to get those feature requests in. We'll endeavour to get as many implemented as we can. Any ridiculous or unobtainable goals will be identified as such as quickly as possible so people don't get their hopes up only for me to dash them like an abusive husband.
Thanks for all of the Froyo deliciousness you've provided us with! I myself will be waiting with baited breath for the next installments of Froyd.
p.s.
If you need more people with access to Exchange, or if you'd like an Exchange environment to play around with, let me know. I've got an Exchange 2010 machine sitting next to me.
Looking great! Hope you'll get that all working!
acolwill said:
Thanks for all of the Froyo deliciousness you've provided us with! I myself will be waiting with baited breath for the next installments of Froyd.
p.s.
If you need more people with access to Exchange, or if you'd like an Exchange environment to play around with, let me know. I've got an Exchange 2010 machine sitting next to me.
Click to expand...
Click to collapse
Ah, now that -would- be useful. [email protected] if you want to hit me up on GTalk.
maxisma said:
Looking great! Hope you'll get that all working!
Click to expand...
Click to collapse
Cheers bud! Check your PMs.
wow keep on the great work...
Flash? 10char
dpi295 said:
Flash? 10char
Click to expand...
Click to collapse
Impossible, it doesn't work on ARMv6 CPUs.
Ah, now that -would- be useful. [email protected] if you want to hit me up on GTalk.
Click to expand...
Click to collapse
Req sent. Gimme a nudge
dpi295 said:
Flash? 10char
Click to expand...
Click to collapse
Best we can do is see if we can hack over the Flash Lite stuff from Sense, but don't hold your breath.
In fact, you all should start a campaign and hammer the **** out of Adobe to provide an armv5te or armv6j version of the flash library. It's their fault, make them fix it.
Hacre said:
Best we can do is see if we can hack over the Flash Lite stuff from Sense, but don't hold your breath.
In fact, you all should start a campaign and hammer the **** out of Adobe to provide an armv5te or armv6j version of the flash library. It's their fault, make them fix it.
Click to expand...
Click to collapse
They won't do that, they aren't powerful enough..
I'd appreciate it if you would make an optional patch for people who want their phone unlocked by double clicking menu button.
Amazing work! Data Partition, Themes, VillainSettings... cant wait!
As for Feature Requests, +1 for a quick 2D Gallery
Nice post ninpo.
Thanks for your great ROM. I'd love to see better rtl language support in your ROM.
Really lame request, and probably easily fixed just by finding the pictures myself, but could you put all the nice wallpapers you had back into the releases?
It's obviously a very trivial request, but the wallpapers were always exceptional compared to my attempts of being sophisticated. I always ended up with either breasts or something Xbox related...
mobydeek said:
As for Feature Requests, +1 for a quick 2D Gallery
Click to expand...
Click to collapse
+1 for the standard 2D Gallery.
Tanks guys for your hard work.
Sent from my HTC Hero using Tapatalk
Woah, that's a lot of things to do, and some big ones too. Good luck on that, would be awesome to see these things done in the next months, though, take your time, no rush .
As for Feature-Requests: I only have one, and I don't have any idea if it's already done (I don't test many ROMs that often, I'll prefer to stay on my 2.1 Vanilla ROM ) or if it's even possible, so sorry for my Noobishness in advance. Now, I would love to be able to control the Music Player with the volume keys. Short presses change the volume, like before, and long presses skip the songs.
Screatch said:
I'd appreciate it if you would make an optional patch for people who want their phone unlocked by double clicking menu button.
Click to expand...
Click to collapse
Blue-K said:
Woah, that's a lot of things to do, and some big ones too. Good luck on that, would be awesome to see these things done in the next months, though, take your time, no rush .
As for Feature-Requests: I only have one, and I don't have any idea if it's already done (I don't test many ROMs that often, I'll prefer to stay on my 2.1 Vanilla ROM ) or if it's even possible, so sorry for my Noobishness in advance. Now, I would love to be able to control the Music Player with the volume keys. Short presses change the volume, like before, and long presses skip the songs.
Click to expand...
Click to collapse
We'll be putting a modified CMSettings back into FroydVillain in 1.3, so these features will be there automaticallymagically.
Yeah, it's a fair bit of work, but with HTC pretty much ditching the Hero we can take the project and make sure it's all done and done right.
There's collaboration with other developers on other projects for a lot of this, it's not just me or Team Villain making it all happen. I'll be pushing the fixed cpuprofile up to cyanogenmod and they can then work on it too, I'm working with Elemag on the 2.6.34 port, Maxisma brought the repartitioning stuff to everyone's attention for the Hero, etc. Proper open source development at its best.
It's well worth it too. Look how different the Hero runs with FroydVillain 1.2.1, I'm quite frankly disgusted that HTC never, ever, tapped all that potential.
I can't believe it, my hero will never die!
This is indeed great news and I can't wait!
I just wanna thank everyone involved, all the developers are doing a fantastic job bringing us things i never thought was possible on the hero, and I totally agree Hacre, it's a real shame that HTC ditched ther hero when there's still juice left in it!
Cheers!
e2zippo said:
I can't believe it, my hero will never die!
This is indeed great news and I can't wait!
I just wanna thank everyone involved, all the developers are doing a fantastic job bringing us things i never thought was possible on the hero, and I totally agree Hacre, it's a real shame that HTC ditched ther hero when there's still juice left in it!
Cheers!
Click to expand...
Click to collapse
Not to mention juice they never, ever bloody gave us. Grr.
Disclaimer: I am only a flasher. I do, however, contribute to the forums, donate to devs and also use the paid version of good apps.
My question is: How does Android work on our phones?
You have hardware (HTC Incredible); you have a carrier (Verizon, in my case); you have an OS (Android, obviously); you have a radio; you have a ROM; you have a kernel; you have themes, you have skins and you have apps. How do all these pieces interact? Just curious.
This is a really good question that should be answered in laymen's terms. I'm surprised it hasn't been answered yet.
I also thought it would have been answered by now. However, I think the developers (who would be the best folks to answer this question) are busy working with the Gingerbread source code to build new ROMs for us.
This is what I have figured out so far but I'm not sure if my analysis is correct:
After selecting your hardware and carrier, the OS is the most important element. Most of us are currently on Froyo (2.2). I have seen some screen shots showing the OS version to be "2.2.1" but I am not sure why. Google (I think) has released the source code for Gingerbread (2.3) and the developers ("devs") are hard at work producing new ROMs as I post this.
I gather that it is best to stay away from trying out different radios ("basebands"). Most of us are using 2.15.00.07.28.
I think the ROM takes the OS and re-works the user interface by adding, removing and changing the various screens and "features" of the OS. For example: the ROM can be written to take out the stock music player and substitute a music player that the ROM developer prefers. I think this is called "baking in an app". I believe the ROM developer can also create an overall "look and feel" that can be quite different from the stock OS. For instance, the ROM can be "colored" in black and red (rather than the stock green) and the stock font can be changed to something the developer prefers. In other words, the ROM is what you see and use on a daily basis.
Now this is where things get a little fuzzy: the kernel. I think this is kind of a behind the scenes element that governs the performance of a ROM. It greatly affects things like battery life, time to charge the battery and the "speed" of the phone. The kernel is where the phone can be "over-clocked" and "under-volted" should you want to do those things. I gather that once you select a ROM, you can try different kernels without changing what the various screens look like on the phone. I believe this is the way most people do it (pick a ROM and try different kernels with it). I don't think the other way really works (pick a kernel and try different ROMs with the kernel).
Next comes themes and skins which really only affect what you see on the various screens without do anything about battery life or the speed of the phone. I haven't played with these much.
Finally, I forgot to put WALLPAPER on the list in the original post. I believe this only appears as a background image on the home screens.
If any reader sees errors in my layman's analysis, please, by all means jump in and correct me. Per my disclaimer in Post #1, I am just an ordinary user and this analysis could be flawed or incorrect in whole or in part.
Everytime I try to answer a question like this, I get too complex about it and leave more questions than answers. Then someone comes along and says "It's like Windows or Linux or MacOS on a PC", and that's that. Well they're right. Those OS's tell the PC's that they are PC's and essentially all OS's do the same things.
Here's my simplified new list:
1) Hardware on phone :: meaningless without OS
-- (android OS - or any other OS)
2) Linux kernel understands hardware like touchscreen, radios, I/O (drivers/modules). Of course it also understands how to schedule processes and all those "kernel tasks".
3) Libraries provide APIs (Application programming interface) to userspace code (like APPS).
4) Userspace (apps, scripts, libraries) provide user control over the phone.
--
Together they work in harmony (we hope) to make the phone realize it is a phone and allow us to use it as such. (well, a smartphone, so many things other than a phone).
Here's a simple example: You touch the phone icon which is in userspace, and it brings up the userspace phone app. As soon (or before) as you touch some buttons, dial a number, it is using the API to the driver in the kernel that actually understands the phone hardware/radio. Also userspace controls GUI which is also requiring API to some form of OPENGL API that is requiring device drivers that get the touchscreen/LCD display. and so on.
--- Hashi
PS: I realize there are a thousand things wrong with this representation, but hey, it's a start. Feel free to fix it up if you're inclined.
Just telling you guys the story first.
I have this spare HD2 lying around after getting the Sensation which also has a severely cracked screen (LCD working, and screen protector on top to prevent injured fingers when using ). A thought occurred to me: Why not build Android to function like an iTouch? I.e: Remove anything related to the SIM card/ remove everything that involves making calls, SMS, etc but retain the functionality of Android apps etc(As I will be using DATA SIM). Most importantly, I want it to be fully optimised for those (I believe that the phone/sms functions running in the background would affect the full potential for the HD2 running music, video, and other apps). I do know how to flash ROMS, and customise downloaded ROMS (e.g: Slipstreaming apps I want, remove some apps I don't want, customise build.prop, etc) and also some programming (a bit of obj-C, a bit of C#, and lots of VB.NET). However, I do not know how to build Android from scratch. Hence I would appreciate if:
-I can get devs to assist me in building Android from source code and customise it so it fits my expectations
-I can get support for this project as I plan to release my work to the public when its done
I will give credit to those who helped. Thanks.
Reserved for future use.
Reserved again.
arikyeo said:
Just telling you guys the story first.
I have this spare HD2 lying around after getting the Sensation which also has a severely cracked screen (LCD working, and screen protector on top to prevent injured fingers when using ). A thought occurred to me: Why not build Android to function like an iTouch? I.e: Remove anything related to the SIM card/ remove everything that involves making calls, SMS, etc but retain the functionality of Android apps etc(As I will be using DATA SIM). Most importantly, I want it to be fully optimised for those (I believe that the phone/sms functions running in the background would affect the full potential for the HD2 running music, video, and other apps). I do know how to flash ROMS, and customise downloaded ROMS (e.g: Slipstreaming apps I want, remove some apps I don't want, customise build.prop, etc) and also some programming (a bit of obj-C, a bit of C#, and lots of VB.NET). However, I do not know how to build Android from scratch. Hence I would appreciate if:
-I can get devs to assist me in building Android from source code and customise it so it fits my expectations
-I can get support for this project as I plan to release my work to the public when its done
I will give credit to those who helped. Thanks.
Click to expand...
Click to collapse
arikyeo said:
Reserved again.
Click to expand...
Click to collapse
arikyeo said:
Reserved for future use.
Click to expand...
Click to collapse
Sir, i seriously doubt your state of mental stability.
And as for your request, the best you can do is use in Airplane mode and switch on wireless. Works for me when i don't want to waste my battery.
Just so that you know, the Qualcomm processors have 2 ARM CPUs on the die, 1 for Radio(Wireless/bluetooth/GSM etc) and 1 for the General purpose/Logic etc... I don't think GSM functions and the phone app running in the background would even mean or translate into anything near a burden or even something which would affect the performace for the CPU in your HD2.
you're pretty much dead-end on this one mate.
android is built ground-up for use in mobile phones. look at those cheap shenzen tablets..they all have no network icon in top bar, and com.android.phone must be running. removing this will only result not working phone as these also include core services-market access etc
only hope you have for doing what you want is to somehow get honeycomb workin' on qsd8250 and tiny fingers to interact with it.
imho best bet would be to just install CM or MIUI, and hide phone etc from launcher.
refer to post above for "very exact explanation" of everything you are trying to do
Hello everyone...I'm planning on trying to develop a gingerbread kernel for AOSP because we don't really have support anymore and everyone has moved onto developing for ICS (not that this is a bad thing). I figure in my spare time I might as well try to learn and develop for our phone. Let me start by saying I was never really into phones/smartphones/rooting, or software development, but I've always been fascinated by Linux in general. I've played around using a number of Linux distros, but I've never really done anything intensive with them (modified their kernels, etc.) but I am vaguely familiar with terminal usage.
Anyways that was just my introduction. I've been running an ICS kernel on my AOSP GB system (specs/stuff in my signature) and while most advised against it, I find it to run pretty well. I'm not sure why it seems to run so well on my phone, but it's basically solved most of my problems (or at least it appears to have done that), but I know the kernel isn't "optimized" for my phone. Some major things people have said are that the ramdisking operations/system is totally different when comparing ICS and GB. This kernel that I'm using is running pretty well, even knowing this fact. What I was wondering is if I could basically get the ICS kernel, then "merge it" with a GB kernel's parameters that pertain to the ramdisk/other major options of GB. That would probably make it better. Also, people stated that multitouch issues for the DINC2 occured on Aeroevan's 0.8 kernel, but not on the 0.7 kernel. This was the changelog stated by aeroevan:
v0.8: Upstream CyanogenMod changes + small touchscreen driver update from HTC. Only tested on my CM7.2 Kang build.
Click to expand...
Click to collapse
So maybe this "small touchscreen driver update" is the thing that caused it, but I'm assuming many other kernels applied this update too? Maybe there is a way to roll back to whatever was in 0.7 in this sense to get rid of the multitouch bug that plagues some people.
I have a pretty powerful laptop, so development shouldn't be too bad. I plan on running Ubuntu 11.10 (or whatever people find suitable these days) in a Virtual Machine and I plan on compiling stuff from there. I am not claiming I know everything or that these things are correct....I am simply just throwing out some brainstorming to get some ideas out there. I know GB is "old", but I (and some others as well) enjoy it's stability and that it generally functions perfectly. Maybe this thread will get a look from popular devs, or maybe it'll get a look from people who just know this stuff. Thanks for reading, and sorry for the length of the post.
Looking forward to your progress on this.
Sent from my ADR6350 using xda premium
It would be nice to have another kernal for AOSP other than aero.
Your help in developing AOSP kernels would be fantastic.
Thanks given. Because I am hard of hearing I cannot use any of the kernels (even Evan's) and have to stick to Sense
Hi!
I have great respect for the people that give us our great ROMs, and i KNOW that that is hard - but my question is: why exactly is it that hard?
This is just a question out of curiosity, because I would really like to understand the unerlying problems that cause all the other issues.
I was under the impression that the Android stack runs on top of the Linux kernel.
Usually, the Linux kernel is the Hardware Abstraction Layer, and apps and ROM, in theory, should be kind of hardware agnostic?
e.g. the Bluetooth Issue on our Captivate Glides: I would guess that Android communicates, through some API, with the kernel's BT stack/driver. There must be some (open or closed source) driver available (worst case: some .so module ripped out of an official ROM, maybe?). So why does the headset profile not work? Did the APIs change? Are custom ROMs forced to use another version of the driver?
It also happens to this 50$ chinese tablet i have here: some ROM screw up the touchscreen, some break audio, and so forth. Why can't there be some way of installing a generic ROM, and then side-loading the OEM's drivers?
Thank you again to all ROM developers! This is NO WAY a complaint. Just pure curiosity!
I may be out of my league when trying to describe this, but the processor in our phones is somewhat different to the processor in the bulk of other phones. This is where majority of the issues came from in porting ICS to the glide before ATT released it. Even after the first official ICS update, the modders here were the ones who fixed the keyboard lights... I changed up to JB because the GPS wasn't locking quick enough and PACROM had all the quick toggles and the speed/gps lock I needed.
Sure the kernel is the underlying part that pulls it all together, even still there is all the drivers that need to work with it. If there isn't a bluetooth/wifi/HW Video driver for the version of the kernel, then it gets really tricky and now its coding for a piece of software to speak with the hardware ..... We have things that partially work, but not fully ...as with everything computers, in theory things that "should" work, don't always... I'm an IT tech.. I run into weird **** all the time that "should" work ... takes time, but with persistence and the right skillset, majority of the time a resolution can always be found.