Without the inclusion of proper documentation included with an Android Rom or an Android Build users will start filling up the HD2 Android Development Forum with why this wont work when it does on someone elses Rom. To stop this from happening there will be a requirement when creating a Thread for a Rom with Android included, or an Android Build.
------------------------------------------
------------------------------------------
If you are making a Rom with Android built in or an Android Build that is run from haret then please INCLUDE with your file a readme.txt file in the ROOT of your release archive with the following information:
*What BUILD version?
An internal version # that can be used to identify the authors exact release (e.g. my-rom-v0.5.zip) for easier reference for the users and fellow developers benefiting from the release.
*Which kernel image and kernel modules are used?
Where are zImage and modules.ko originally downloaded (in case the chef didn't compile on their own) and where is the kernel source code for the kernel and modules.
In case the chef did not compile on his own, he should still be able find out where the source code is.
(The license under which the Linux kernel is released requires the distribution of the source code that was used when distributing builds.)
*What rootfilesystems are used?
Where was it taken from, what does it include (android version it's based on etc) and in case of self compilation, where is the source code.
(In case of most windows mobile shipped devices that's often some rootfs file e.g. named android.ext2 and an initial ram filesystem often named initrd.cpio.gz).
*ChangeLog*
A ChangeLog is really an essential addition in every build as it informs the end user what modifications have been made from the last build. This will save you ALOT of questions as to what has been added, deleted or modified and therefore is a requirement for everyones benefit.
*WindowsMobile version your Android Build was tested on*
Please include your WinMo Build version, HTC OemDrivers (if known), XIP (if known) and Radio version so that users know what the Android Build was tested on and can replicate if neccessary for fault finding purposes.
------------------------------------------
------------------------------------------
If you are unable to obtain any of this information and thus can't make it available through an included readme.txt you should not distribute your rom and keep it for personal use only.
If you are using an exact copy of a present release (e.g. in case of a WinCE rom that has an android 'dual boot' option) you must include the readme.txt from the original rom chef.
If you release a Rom and do not have the required information then you will be asked to either create and include a readme.txt file with your Rom or ask for the thread to be deleted.
If you have any comments or questions on this please feel free to post.
Mark.
** reserved **
Thanks a lot for the quick action, Mark. I am glad to see a first positive response.
If this will establish I hope that
*users are informed about what they get
=>less unneeded questions and thus more room for constructive feedback
*developers have an easier time to benefit from present releases
*new developers must try to get an understanding of what they are doing
=>more quality releases
The original post can be found here.
I think it would be nice to hammer out the readme.txt requirements together with chefs so we can get some convention that satisfies everybody.
edit: Think it will really be good to always put readme.txt in root of release archive so everybody knows where to look for it.
dcordes said:
edit: Think it will really be good to always put readme.txt in root of release archive so everybody knows where to look for it.
Click to expand...
Click to collapse
Edited the 1st post to include this
Mark.
Will be following this convention for any future releases
DarkStone1337 said:
Will be following this convention for any future releases
Click to expand...
Click to collapse
Thank you
Future releases soon I hope lol
Mark.
May I suggest that the readme include the date of ROM compilation, as well as the date the kernel and root file systems files. I think this will help users and chefs to easily build there own compilations and keep track of it's validity.
And a title format like: [date]-[name]-[version]-{[kernel]-[kerneldate]}-{[modules]-[modules-date]}-[rootfs] (just like rules for 'regular' roms). Both for the post and the archive preferably?
Personally I switch between versions a lot, to find differences/improvements/bugs.
Clear archive-naming should simplyfy this .
Excellent rules! We need to improve stability of ports and eliminate all unnecessary questions !
P.S. Hope there won't be any "bogus", or "copy-paste-claim" ROM-s.
dcordes an mskip +1
ahbad said:
May I suggest that the readme include the date of ROM compilation, as well as the date the kernel and root file systems files. I think this will help users and chefs to easily build there own compilations and keep track of it's validity.
Click to expand...
Click to collapse
Very good idea. I think we should at least add the rom release date to minimum required readme.txt information.
For the rootfs release date I think we should leave it up to the chefs because I think it will be hard to find out in many cases. Reason is rootfilesystems get passed on 20 times...
In case of the kernel release date it might be a good idea to add it. should be easy to find out. When you grab the kernel e.g. from the two sources I link to in the thread
http://oe.netripper.com/files/htcleo_autobuild/
http://cotulla.pp.ru/leo/Android/
you can just copy paste the date from filename or information on the site. This would be very useful assuming the kernel images will be removed at some point.
On a side note: For both kernel examples the source code repository to add in readme.txt is
git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git htc-msm-2.6.32
gitweb: http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=shortlog;h=refs/heads/htc-msm-2.6.32
So currently in every leo rom readme.txt this must be linked to as kernel source reference. netripper autobuild zImages using this exact source code and cotulla zImages share same codebase (although currently the latest changes are unavailable but will be added in git soon)
shufflez said:
And a title format like: [date]-[name]-[version]-{[kernel]-[kerneldate]}-{[modules]-[modules-date]}-[rootfs] (just like rules for 'regular' roms). Both for the post and the archive preferably?
Personally I switch between versions a lot, to find differences/improvements/bugs.
Clear archive-naming should simplyfy this .
Click to expand...
Click to collapse
To me that seems over exaggerated. Rom version in file name should be enough. Rest can be looked up in readme.txt
So what does everybody think? If we add the release date of kernel and completed rom, do we have an agreement ? In that case we should compile an example and add it in the first post.
best regards
your right dcordes too much information in the title can be a bad thing. Something more like
[Date] [Name] [Version] [Build] [maybe Kernel version]
That should be Enough i think so for Example
[21/07] [Darkstone1337] [v5] [Eclair w/sense] [2.6.32]
Everything else should stay a change log for people to read
David Balfour said:
your right dcordes too much information in the title can be a bad thing. Something more like
[Date] [Name] [Version] [Build] [maybe Kernel version]
That should be Enough i think so for Example
[21/07] [Darkstone1337] [v5] [Eclair w/sense] [2.6.32]
Everything else should stay a change log for people to read
Click to expand...
Click to collapse
I am sticking with my opinion:
*in filename require internal chef rom version
*in readme.txt add:
-rom release date
-kernel release date
Mark what do you think? Any other opinions?
Install to folder
May be a good idea install all files to appropriate folder, not directly root of SDcard as in last darkstone FROYO. Greatly simplify process of testing and changes between several images and don't messy root. Switching between different versions is than as easy as renaming directory.
I think we should also leave directory structure etc to the chef as long as readme.txt with all the required information exists in archive root so users can find it easily.
so do we have some agreement here? Mark ? If so you should update the first post to compile final set of information needed and clarify that it is not a nice extra but a requirement.
dcordes said:
I am sticking with my opinion:
*in filename require internal chef rom version
*in readme.txt add:
-rom release date
-kernel release date
Mark what do you think? Any other opinions?
Click to expand...
Click to collapse
I agree with you on this theres no need to make things more complicated than they need to be. Although there does need to be some sort of standard for the thread title.
And no I cant think of anything else right now that needs to go in.
dcordes said:
I think we should also leave directory structure etc to the chef as long as readme.txt with all the required information exists in archive root so users can find it easily.
so do we have some agreement here? Mark ? If so you should update the first post to compile final set of information needed and clarify that it is not a nice extra but a requirement.
Click to expand...
Click to collapse
Also agree that its upto the chef how they want their files set up as long as its clearly stated in the readme.txt what to do to get it working.
Everything sounds fine What needs adding to the first post to make it complete?
Sorry I have been working on my Loader but its all finished now (I hope).
Mark.
HD2 Android Image & Instructions
Hi All,
Can somebody confirm if there is a working Android image for the HD2 yet? From reading previous threads, it would seem there is still some technical challenges, no image is available yet.
If I am wrong, please could somebody tell me the location of an image and instructions so I can install Android on my HD2? I am struggling with WM6.5 and I much prefer Android. I have used WM for 9-years now but it just doesn't compare - partially because there are limited decent apps available.
All the best,
Youdaler
youdaler said:
Hi All,
Can somebody confirm if there is a working Android image for the HD2 yet? From reading previous threads, it would seem there is still some technical challenges, no image is available yet.
If I am wrong, please could somebody tell me the location of an image and instructions so I can install Android on my HD2? I am struggling with WM6.5 and I much prefer Android. I have used WM for 9-years now but it just doesn't compare - partially because there are limited decent apps available.
All the best,
Youdaler
Click to expand...
Click to collapse
I will just give you a friendly warning this time as it is your first post. This thread is for the discussion of information to be included by Android builders.
If you look in the Android forum then you will see working builds by DarkStone and by Dan1j3l. Look at their threads for how to load Android. to answer your question yes Android does work (95%) on the HD2.
Please confirm you have read this so I can delete these posts and keep the thread clean. In futured please only post in the correct thread and if you arent sure then post in the Q&A thread at the top of the Android forum.
Mark.
Understand. Thanks for clarifying.
I think we should extend the readme.txt items with some section like 'expected issues' or 'known problems' .
And in the readme.txt , could help too:
Tested with:
-WinMo rom x.xx.xx
-Radio rom 2.xx.xx
Sent from my HTC Desire using XDA App
I was just looking through build.prop and thought to myself that I could put whatever I wanted to in the Android version and Build number fields. My Android version is now my name, and the Build version my address.
But you could put whatever you want there, so why not tag your phone? I am sure you guys could come up with something much more cool to write....
Hello,
I'm checking the official list of android build numbers on the android homepage ( http://source.android.com/source/build-numbers.html ), and I find some things strange..
First one, why is the build number ITL41D repeated for android-4.0.1_r1 and android-4.0.1_r1.1? isn't this a typo?
Secondly, When I got my Nexus 7, It had pure android 4.1 and the build number JRN84D, but that build number doesn't appear on the list?
Third, related to the second question, I don't find android-4.1_r1 on the list, which may be why JRN84D is missing, but I also can't find android-4.0_r1.. anyone knows why are those missing?
Fourth, cupcake wasn't using build numbers?
Thanks everyone.
Noone knows?
up
I've been watching and waiting for the G900TUVU1ANCH source code on Samsung's website, but all they have available right now is G900TUVU1ANCD. Two questions:
1) How long does it typically take Samsung to release the latest version of source code after the firmware has been pushed to devices (or manufactured with said version)?
2) Are there any other avenues to obtain the source code (i.e. through carrier, via leaks, per request)?
I'm looking at trying my hand at porting native Ubuntu Desktop to the S5, but I would like to start with the current/latest kernel.
FYI, one of the reasons I moved from the S4 -> S5 was because of AT&T's ridiculously locked bootloaders, making native booting to Ubuntu Desktop or Ubuntu Touch very difficult - and impossible to make an "easy" way of switching between this and Android seamlessly (i.e. via a boot menu of sorts).
Aou said:
I've been watching and waiting for the G900TUVU1ANCH source code on Samsung's website, but all they have available right now is G900TUVU1ANCD. Two questions:
1) How long does it typically take Samsung to release the latest version of source code after the firmware has been pushed to devices (or manufactured with said version)?
2) Are there any other avenues to obtain the source code (i.e. through carrier, via leaks, per request)?
I'm looking at trying my hand at porting native Ubuntu Desktop to the S5, but I would like to start with the current/latest kernel.
FYI, one of the reasons I moved from the S4 -> S5 was because of AT&T's ridiculously locked bootloaders, making native booting to Ubuntu Desktop or Ubuntu Touch very difficult - and impossible to make an "easy" way of switching between this and Android seamlessly (i.e. via a boot menu of sorts).
Click to expand...
Click to collapse
Not sure about the platform source, but the CH release appears to use the same kernel sourced in the Samsung released labeled CD. They're both (rather erroneously) tagged as kernel version 3.4.0. I used the current source to build a kernel here http://forum.xda-developers.com/showthread.php?t=2729338 which works exactly as expected. I'm guessing CH was just a baseband release at this point.
Samsung has historically been pretty timely about pushing new sources, usually within a week or so.
Good luck.
zaventh said:
Not sure about the platform source, but the CH release appears to use the same kernel sourced in the Samsung released labeled CD. They're both (rather erroneously) tagged as kernel version 3.4.0. I used the current source to build a kernel here http://forum.xda-developers.com/showthread.php?t=2729338 which works exactly as expected. I'm guessing CH was just a baseband release at this point.
Samsung has historically been pretty timely about pushing new sources, usually within a week or so.
Good luck.
Click to expand...
Click to collapse
Gotcha. If it was indeed just a baseband update or something irrelevant to the open-source parts of the firmware, then I guess there wouldn't be anything to update on Samsung's website. I'll probably stick with the *CD source and use it like you did. Thanks.
For that matter, has anyone captured the *CD -> *CH update as a .zip? Would have required root at that time to snag it, and I came into the S5 game a few days late (not sure on the sequence of events here)... In any event, if it were captured, it would tell us exactly which components were updated, and if building stuff from the *CH source is required for anything specific.
Lastly, minor updates typically don't touch the kernel, so I think you are absolutely right, @zaventh.
I ve got an S7, which hasn't been updated for a while.
Now I m looking that those are the latest android (8) rels:
PDA G930FXXS8ETC3 and CSC G930FEUR8ETC1 (MAR2020)
PDA G930FXXS7ETA4 and CSC G930FEUR7ETA1 (JAN2020)
I would like to know where can I find a list of changes for each of those releases (but also for any release in general). I mean what's fixed, what's improved etc.
I m currently on build G930FXXS6ESI4 (SEP2019)
Do which (official) version should I upgrade to (if there are notable improvements). I m only asking because from experience, the 'latest' isn't always the best.
Cheers
https://developer.android.com/about
jwoegerbauer said:
https://developer.android.com/about
Click to expand...
Click to collapse
That's a nice resource, but it doesn't mention changes per build - which is what I m concerned about.
It only refers to features implemented in API level 26 (8) and not in detailed fixes per build e.g. changes from G930FXXS7ETA4 >>> G930FXXS8ETC3