Related
We have had alot of activity over the last few days, what with the first 2.0 releases from the main players and now even some 2.1 builds. Which is excellent.
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd.
The reason I raise this point, is because I dislike the Rosie/SenseUI on my Hero, I would rather have the good, old Android standard like I had on my G1 - just what I prefer. However there are only beta versions of the AOSP eclair for Hero.
Would it be possible to build an AOSP eclair firmware, using the Qualcomm? proprietory drivers from someones leaked 2.1 image (working on an assumption that 2.1 has the same kernel base?) to produce a fully working Eclair 2.0 for Hero?
If I am way off the mark with this, please say, I'm just trying to think it through with the help of the people in the know.
Ditto. I am all for AOSP 2.0
richbayliss said:
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd
Click to expand...
Click to collapse
I think part of the "issue" is that whilst Google have release some 2.0 code to AOSP, it is not currently complete (see here). In addition, many of the Google apps (e.g. Gmail) are closed source, so you have to rely on prebuilt components which may, or may not, be compatible.
The long and short of it is that Lox is already doing what you are asking. The prerelease of HTC's 2.1 has possibly served as a distraction to the AOSP 2.0 build, but I'm sure once Google properly drops AOSP 2.1 code that work will be of direct relevance to the AOSP project.
Regards,
Dave
yeah exactly. just sit tight and wait for Lox_dev to finish his 2.1 Then he might look after the AOSP 2.0. and as AOSP 2.0 is running pretty fine without much hassle its fine if Lox takes some time before working on AOSP 2.0 . cheers
I'm with this idea!
I mean, just compare the 2.1 and 2.0 aosp videos; android 2.0 has much cleaner, and better transitions imo.
Design choices in 2.1 by HTC are, imo, bad as usual; the transparent notification drawer for example; what is the purpose? It's only jerky. And so on..
I suggest suspending judgement on HTC's 2.1 until they've actually released final code! Remember this is a leaked internal build - what ends up in the final ROM may be quite different.
Regards,
Dave
I think I have a clearer picture now, thanks guys.
I just wish that we could be in a scenario where we could flash a standard AOSP build onto our Hero's, sans the whole SenseUI, and have a basic usable phone.
I really dont get the whole "gmail is closed source" crap with Google. I mean, I can have Gmail on WinMo, S60, etc - but only on Android IF I have a license?? WTF! Crazy! Luckily, now that Gmail does support Exchange Activesync I don't need the standalone app anyway.
So the word on the street is wait.... which I guess is what we will have to do
I am keen to be able to build from source so I can start on a project I have in mind. Think along the lines of SenseUI, but a bit different.....
richbayliss said:
We have had alot of activity over the last few days, what with the first 2.0 releases from the main players and now even some 2.1 builds. Which is excellent.
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd.
The reason I raise this point, is because I dislike the Rosie/SenseUI on my Hero, I would rather have the good, old Android standard like I had on my G1 - just what I prefer. However there are only beta versions of the AOSP eclair for Hero.
Would it be possible to build an AOSP eclair firmware, using the Qualcomm? proprietory drivers from someones leaked 2.1 image (working on an assumption that 2.1 has the same kernel base?) to produce a fully working Eclair 2.0 for Hero?
If I am way off the mark with this, please say, I'm just trying to think it through with the help of the people in the know.
Click to expand...
Click to collapse
Forgive me if I'm missing the point, but we already have a fully working AOSP Eclair image for the HTC Hero. I've been using it for over a week, on a daily basis and other than the looping sync issue (which we are working on) it works fantastic..
jnwhiteh said:
Forgive me if I'm missing the point, but we already have a fully working AOSP Eclair image for the HTC Hero. I've been using it for over a week, on a daily basis and other than the looping sync issue (which we are working on) it works fantastic..
Click to expand...
Click to collapse
I wasn't aware that all issues apart from the syncing were fixed. I thought we still had issues with camera stability etc?? Is this not the case??
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
jnwhiteh said:
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
Click to expand...
Click to collapse
Believe me, I'll come back to AOSP soon with great things
That's an awesome news ! Thank you Lox !
Lox_Dev said:
Believe me, I'll come back to AOSP soon with great things
Click to expand...
Click to collapse
Thanks Lox, appreciated.
Lox_Dev said:
Believe me, I'll come back to AOSP soon with great things
Click to expand...
Click to collapse
Great news man! Thanks a lot! Holding my breath...
jnwhiteh said:
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
Click to expand...
Click to collapse
I agree. The only reason I am now using Lox_devs Hero 2.1 1.4 instead of the pure Eclair one is that Eclair does not sync my exchange calendar. I just cant see why the calendar has been left out.
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.
Is this project treble?
No
halleyrokz said:
Is this project treble?
Click to expand...
Click to collapse
That is the security patch level of android. You can get more info about project treble here.
For everyone getting excited over Treble should keep this in mind
"Project Treble doesn’t necessarily mean that all handsets will see updates instantaneously, as Google is not handling them directly. OEMs are still free to tweak and skin the OS, as well as embed their own software into the Android OS release. So there’s still going to be some time taken for OEMs to build and test their own particular take on Android."
zelendel said:
For everyone getting excited over Treble should keep this in mind
"Project Treble doesn’t necessarily mean that all handsets will see updates instantaneously, as Google is not handling them directly. OEMs are still free to tweak and skin the OS, as well as embed their own software into the Android OS release. So there’s still going to be some time taken for OEMs to build and test their own particular take on Android."
Click to expand...
Click to collapse
Spot on. Treble just eliminates the need for new drivers, so OEMs don't need to wait for part manufacturers (like Qualcomm). But OEMs (Samsung, LG,...) are still the main culprit when it comes to wait times or not getting updates at all.
If community can make a custom ROM for a 5+ year old device, so can an OEM. Drivers are obviously there, they're just not interested in updating anything for more than 2 years (even less in case of low and mid range devices). Treble can't change that.
The only real solution would be "one size fits all" system, that gets pushed directly by Google to ALL devices - like desktop systems. But that would probably be way to big for available storage on phones ...
Sent from my OnePlus 3 using Tapatalk
Explorer23 said:
The only real solution would be "one size fits all" system, that gets pushed directly by Google to ALL devices - like desktop systems. But that would probably be way to big for available storage on phones ...
Click to expand...
Click to collapse
We're going very offtopic here, but the topic interests me so, eh.
If we're talking about size here, we can follow a method that has been used in Linux live systems for a while now: a tarred (.tar) or squashed (squashfs) images. These provide a small yet ”fast enough” images that can be smaller than their uncompressed counterpart. Size is not of the constraint nowadays with these at developers disposal.
Alternatively, you can have a system that Treble tries to achieve: a base image (AOSP), OEM-specific changes and drivers, and abstraction for said drivers and changes. This system still relies on OEMs (and SoC manufacturers to an extent) to actively update their changes to the base system (and we know how lazy some OEMs can be with their updates).
But this is very offtopic, so let me offset the talk a little.
------------
To OP: No, that is not Treble. Treble isn't something you can quite see in user space (i.e Settings app). What you're pointing out is the security patch level, that is, how "updated" your current system are to the security patches Google are providing.
The level is laid out in date, so "November 1 2017" would be a fairly recent update. These patches get updated monthly, and seeing that you're using OxygenOS, means that you'll have to wait for OnePlus to push the security update after Google pushes them.
F4uzan said:
We're going very offtopic here, but the topic interests me so, eh.
If we're talking about size here, we can follow a method that has been used in Linux live systems for a while now: a tarred (.tar) or squashed (squashfs) images. These provide a small yet ”fast enough” images that can be smaller than their uncompressed counterpart. Size is not of the constraint nowadays with these at developers disposal.
Alternatively, you can have a system that Treble tries to achieve: a base image (AOSP), OEM-specific changes and drivers, and abstraction for said drivers and changes. This system still relies on OEMs (and SoC manufacturers to an extent) to actively update their changes to the base system (and we know how lazy some OEMs can be with their updates).
But this is very offtopic, so let me offset the talk a little.
------------
To OP: No, that is not Treble. Treble isn't something you can quite see in user space (i.e Settings app). What you're pointing out is the security patch level, that is, how "updated" your current system are to the security patches Google are providing.
The level is laid out in date, so "November 1 2017" would be a fairly recent update. These patches get updated monthly, and seeing that you're using OxygenOS, means that you'll have to wait for OnePlus to push the security update after Google pushes them.
Click to expand...
Click to collapse
There never can be a one size fits all OS. Even Linux can't really pull that off for every device.
See this is another thing that will never happen. Oems will never upload their code changes to aosp as Google intends. Most of the time due to the fact that they don't write the code for the different parts like BT, Wifi chips etc. This code comes others which is closed sourced and paid for.
Treble will most likely never become much. Already too many people misunderstand what it does. That i can't blame people for. Things like the xda portal that are giving out bad info is gonna cause a huge amount of drama over it.
I just checked out the aospa Twitter page and they are devices that are running the new version of paranoid Android. I am wondering if there are no maintainers for this device as we do not get it built for our devices I believe that it can be built off of source but I know that there compilation methods are abid difficult. Anybody want to take a stab at it and build this wonderful run for our devices. @slothdabski @calsurferpunk @kingbri
I would sport that puppy...
i42o said:
I just checked out the aospa Twitter page and they are devices that are running the new version of paranoid Android. I am wondering if there are no maintainers for this device as we do not get it built for our devices I believe that it can be built off of source but I know that there compilation methods are abid difficult. Anybody want to take a stab at it and build this wonderful run for our devices. @[email protected]@kingbri
Click to expand...
Click to collapse
I read this on their gsi xda post
(NOT using A/B partitioning scheme (ie. A-Only)
Bummer
It's a device specific flag that can be set up to run on a/b devices... It's just a matter of someone picking up the project for our phones.. I do recall that back in the day the way to build it was different from other operating systems so maybe the setup was different and nobody here has that set up possibly? I'm trying to stay patient but I am currently running DU and is running phenomenally.. I do understand that paranoid Android is very barebone right now but the caf source makes it really good on battery low and stability. I recall way back and my Galaxy S2 days ... And this is just a great project. If anyone out there can build this for us you would be incredible
i42o said:
I just checked out the aospa Twitter page and they are devices that are running the new version of paranoid Android. I am wondering if there are no maintainers for this device as we do not get it built for our devices I believe that it can be built off of source but I know that there compilation methods are abid difficult. Anybody want to take a stab at it and build this wonderful run for our devices. @slothdabski @calsurferpunk @kingbri
Click to expand...
Click to collapse
Paranoid Android was very cool in 2013, I used it on my SGS4 back then on Android 4.3. They had this engine where you could set the phone to tablet, phablet or phone mode and change DPI. You could even do this on a per-App basis! Very nice :good:
On top they had a plethora of setting - oh and they had this psychedelic design! E.g. for OTA updates (IIRC) they showed this one: https://www.androidpolice.com/wp-content/uploads/2013/06/nexusae0_lennon.jpg
But now, in 2019, what is special about PA?
BabelHuber said:
Paranoid Android was very cool in 2013, I used it on my SGS4 back then on Android 4.3. They had this engine where you could set the phone to tablet, phablet or phone mode and change DPI. You could even do this on a per-App basis! Very nice :good:
On top they had a plethora of setting - oh and they had this psychedelic design! E.g. for OTA updates (IIRC) they showed this one: https://www.androidpolice.com/wp-content/uploads/2013/06/nexusae0_lennon.jpg
But now, in 2019, what is special about PA?
Click to expand...
Click to collapse
Nothing really, a lot of the stuff that they Incorporated back in the day or something that comes native on Android nowadays.. PA Theme engine is somewhat redundant especially how it lets you theme per app basis somewhat like substratum can do... I don't see Halo coming back, and it wasn't back in the Android 7 or 8 builds of paranoid Android... I will say one of the things that they have going for them would be the caf base.. as I mentioned before it is extremely fluid and great on battery life.. ever since @molesarecoming left the dev scene for this operating system, it honestly seemed to have died as far as what features where available on this... I guess now it's good for nostalgia and stability as far as features go I don't see what they can offer that we don't already get with other options... I can't say this though, the battery life has always been good on these ROMs
This is a bit different than most postings here, as I'm not directly providing any binaries to install on your phone and instead providing a simple tool, rattlesnakeos-stack, to build your own customized ROM based with latest AOSP on a regular basis, with your own signing keys, and your own OTA updates. This probably will be interesting to a small subset of users as it requires some technical knowledge and costs money to run this infrastructure in AWS to produce your own builds.
You can read more about the project here: https://github.com/dan-v/rattlesnakeos-stack
I'm generally more active on the subreddit if you have any questions: https://www.reddit.com/r/RattlesnakeOS/
XDA:DevDB Information
RattlesnakeOS [Pixel 3a], ROM for the Google Pixel 3a
Contributors
dantheman78
Source Code: https://github.com/dan-v/rattlesnakeos-stack
ROM OS Version: Android 10
ROM Kernel: Linux 4.x
Based On: AOSP
Version Information
Status: Stable
Current Stable Version: v9.0.35
Stable Release Date: 2019-09-08
Current Beta Version: v10.0.0-beta.1
Beta Release Date: 2019-09-12
Created 2019-09-13
Last Updated 2019-09-13
I really like the idea. I have some experience in building Android, so I might try this if I find some time. Be prepared for LOTS of questions if I do
flocke000 said:
I really like the idea. I have some experience in building Android, so I might try this if I find some time. Be prepared for LOTS of questions if I do
Click to expand...
Click to collapse
Happy to help answer any question if you decide to make the jump. Also, thanks so much for your work on andOTP, such a great app!
dantheman78 said:
Happy to help answer any question if you decide to make the jump. Also, thanks so much for your work on andOTP, such a great app!
Click to expand...
Click to collapse
Thank you, every time I encounter someone using andOTP I remember how much I love developing it. My main problem is that I don't have any time to spend working on it right now (same as with trying this). Let's hope that changes soon ... :good:
Oh dang! This is way more robust than I expected going into your repo! This is impressive! I like this! I have my own build systems setup locally but I'm digging into this now and seeing what you did better than I did. I have some security features disabled due to vendor being obnoxious. My AOSP infra work is a bit dead in the water until TWRP updates for Android 10 though. Excited to play with this when I can.
So one thing I'm wondering though is, why provide options for building in apps that can trivially be downloaded (and maintained!) From fdroid? Unless I'm missing something, I feel like adding in chromium and pushing every update for that via OTA is fairly excessive.
Helios747 said:
So one thing I'm wondering though is, why provide options for building in apps that can trivially be downloaded (and maintained!) From fdroid? Unless I'm missing something, I feel like adding in chromium and pushing every update for that via OTA is fairly excessive.
Click to expand...
Click to collapse
The primary reason for shipping F-Droid is to be able to include the privileged extension which is configured during the build to only trust your signing key. The privileged extension provides least privilege elevated install/uninstall permissions to make installing/updating F-Droid apps not require 'unknown sources' to be enabled or constant prompts, essentially making it behave like the Google app store.
The reason for shipping Chromium is not for the browser, but for the webview. The standard webview that ships with AOSP is meant for testing purposes, is not updated regularly and likely has security issues. So building a modern webview and keeping up to date is important. The general idea is that the average user would build this once a month and would get an updated webview with each release. If this sounds too frequent to you, you may pick and choose when to rebuild Chromium by locking onto a particular Chromium version in the config file.
dantheman78 said:
The reason for shipping Chromium is not for the browser, but for the webview. The standard webview that ships with AOSP is meant for testing purposes, is not updated regularly and likely has security issues. So building a modern webview and keeping up to date is important. The general idea is that the average user would build this once a month and would get an updated webview with each release. If this sounds too frequent to you, you may pick and choose when to rebuild Chromium by locking onto a particular Chromium version in the config file.
Click to expand...
Click to collapse
Ah. That makes perfect sense. I forgot that you can set system webview providers.