About the time when further existence of Cyanogenmod was endangered because of Google's legal claims, there happened to be a post from the author of Cyanogenmod:
Since I don't work with any of these closed source applications directly, what I intend to do is simply ship the next version of CyanogenMod as a "bare bones" ROM. You'll be able to make calls, MMS, take photos, etc. In order to get our beloved Google sync and applications back, you'll need to make a backup first. I'm working on an application that will do this for you.
Click to expand...
Click to collapse
The current state is that (supposedly) Cyanogenmod build does not contain any Google apps, BUT in fact to install Cyanogen you should first flash a development image from HTC (DRC83 or so) that contains them, and atop of this Cyanogenmod.
My question is, will the current Cyanogenmod build work without the HTC "base" files, in the way it is described in the message quoted above?
I own a Magic 32A. Could I just flash the latest Cyanogenmod update.zip (and another update.zip with appropriate kernel)?
I DO NOT want any proprietary apps on my phone.
(It will suffice if I have a web browser and a basic contact list application, without syncing.)
If anyone knowledgeable in the affairs of "update.zip" format reads this, I would also like to know if the Cyanogenmod's update.zip does only write some files to existing filesystems, or does it first erase/create new filesystems in some areas of flash memory? And what does the update.zip from HTC do (this one is certainly supposed to erase the root filesystem of the device!)? Would applying just the Cyanogenmod's update.zip leave the HTC files in place if they are already there, and how can I clean the root filesystem?
Not sure if that's how it works. Why don't you just remove the apps after?
If you really want Android without Google Apps, you can also compile from the source Android. That will give you basic functionality (phone, contacts, email) without Google Apps on it. You just need to checkout donut branch, instead of eclair's, since eclair is still on development.
Check: source.android.com and follow the documentation to checkout and compile for dream and sapphire
xaueious said:
Why don't you just remove the apps after?
Click to expand...
Click to collapse
The Google's libraries seem to be hiding in every corner, so that's not really clean.
@dferreira
Right, but it is probably some hassle (and I would duplicate some work of the people who publish their images here), also the download would take a long time with my internet connection. Why do it, if it's already done? A stock Android build from AOSP must be hanging somewhere around... but I haven't seen it yet. All the donut images I've seen on this forum had some silly modifications and were prepared to work with Google packages.
(Or is the source prepared nicely enough to work right if it compiles successfully and is put on the device? How do you put the build in an update.zip to allow flashing to a consumer device with a custom recovery image, but without engineering SPL?)
Donut branch should compile and work without a hitch. Even eclair works out-of-the-box, without camera working and 3D acceleration.
The compiled result will be recovery.img, boot.img, system.img, userdata.img... I've flashed them using fastboot Unless you know how to make a update.zip out of these, you should be all set. The update.zip only works if signed with the right certificates for non-engineering SPL devices.
The update.zip only works if signed with the right certificates for non-engineering SPL devices.
Click to expand...
Click to collapse
I wonder how do some folks from this forum do it then?
I doubt they have relations with google employees!
Do you know which kernel trees are compatible with the 3.22.20.17 radio firmware that is found in stock Magic devices?
AOSP has a kernel project and HTC has put some kernel sources at developer.htc.com, but there's only something called "HTC Magic Kernel Source Code" - no mention for which model.
Well, actually, i might do with some of the kernels that lie around the forum, but do they have any special requirements for initrd and modules, that would require modifying the flash images you get from building the Donut branch?
Seems to me that kernel is in the boot.img. You flashed it and everything works. You have not touched the radio firmware. Correct or not?
kguciek said:
I wonder how do some folks from this forum do it then?
I doubt they have relations with google employees!
Do you know which kernel trees are compatible with the 3.22.20.17 radio firmware that is found in stock Magic devices?
AOSP has a kernel project and HTC has put some kernel sources at developer.htc.com, but there's only something called "HTC Magic Kernel Source Code" - no mention for which model.
Well, actually, i might do with some of the kernels that lie around the forum, but do they have any special requirements for initrd and modules, that would require modifying the flash images you get from building the Donut branch?
Seems to me that kernel is in the boot.img. You flashed it and everything works. You have not touched the radio firmware. Correct or not?
Click to expand...
Click to collapse
Yes, the kernel is in boot.img, and it is the AOSP kernel that comes with the source code There is no radio firmware on AOSP.
update.zip is made by issuing make otapackage.
Hi buddy i thought about something like that few weeks ago and i think MarsDroid has already made some version of Android(Very lite MarsDroid SPL 7) fully without Google apps, so try it..
OK, I've built an image from donut source, coupled it with a kernel from a CyanogenMod port, and it works flawlessly on my phone!
I've uploaded the images to RapidShare, should anyone need them Links are at my website (guciek.net/en/stuff/android_builds).
kguciek said:
My question is, will the current Cyanogenmod build work without the HTC "base" files, in the way it is described in the message quoted above?
I own a Magic 32A. Could I just flash the latest Cyanogenmod update.zip (and another update.zip with appropriate kernel)?
I DO NOT want any proprietary apps on my phone.
(It will suffice if I have a web browser and a basic contact list application, without syncing.)
Click to expand...
Click to collapse
Yes, it works fine if you don't flash the 'defanged' update image first.
unfnknblvbl said:
Yes, it works fine if you don't flash the 'defanged' update image first.
Click to expand...
Click to collapse
But it wouldn't erase the whole system partition, so there could still be some files left.
Now that I realised I can flash images from recovery even without engineering SPL, it seems a safer and cleaner way.
Also, I like to have a second ext2 partition on SD card that is only accessible from a computer, and I wasn't able to do this with CyanogenMod, which instantly filled it with apps2sd data, swap files etc...
kguciek said:
But it wouldn't erase the whole system partition, so there could still be some files left.
Click to expand...
Click to collapse
No, that's why you wipe from recovery before installing.
unfnknblvbl said:
No, that's why you wipe from recovery before installing.
Click to expand...
Click to collapse
Actually wiping only erases the data partition, not the system one.
fastboot erase system -w
carz12 said:
fastboot erase system -w
Click to expand...
Click to collapse
Right, but it isn't possible for users with unmodified SPLs.
Actually, you can just flash a image of an empty yaffs filesystem to system partition (it's just a few blocks at most).
Related
GApps2zip
This script makes an update.zip file that only contains the Google Apps from the HTC release of the 1.5 firmware upgrade for the ADP 1. This update.zip should be flashable on any build and it should work without a problem, but since I'm just a n00b sophomore in highschool, I am naturally poor and can't guarantee anything.
Because there are already a few alternatives to this for Linux and the majority of Android users use Windows, I decided to make this a Windows-only batch script.
You MUST have the Java Runtime Environment installed in order to run this script! The signing utility requires Java and you won't be able to flash an unsigned update. If it doesn't work even if you have Java, you may have to reinstall Java as it is not in your PATH variable for whatever reason.
UPDATE: Updated and, as far as I know, should now work fine with the 1.6 developer images from HTC as well as personal NANDroid backups of most all 1.6 Android ROMs.
INSTRUCTIONS
1) Either do a or b. It is advised to use a personal NANDroid backup (b) as it does not violate any licenses, but it has not been testeda) Google for the file "signed-dream_devphone_userdebug-img-14721.zip" It should be on the HTC support page for the ADP 1, but it wont be the first result in Google. It is not advised to use this method as you need to agree to a license prohibiting modification of the file in order to download it. Rename the file to "backup.zip"b) Restore to a regular build that has all of the Google Apps (like the regular OTA cupcake update) and then run a NANDroid backup. Then make a zip file that only has the system.img file from the NANDroid dump and name the zip "backup.zip"2) If you haven't already, unzip the entire contents of the gapps2zip.zip file into a directory. For sake of simplification, I am assuming it is unzipped to C:\gapps2zip
3) Place the "backup.zip" file in the same directory as the GApps2zip.bat file (C:\gapps2zip) and DON'T rename it or unzip it.
4) Open up a command prompt window (Hit Windows + R, type in CMD, then click OK)
5) cd to the directory in which the GApps2zip.bat file, utils directory and the backup.zip file. For example:
Code:
cd C:\gapps2zip
6)Type in "GApps2zip.bat" (without the quotes) and hit enter. Watch and wait.
7) If all goes well, you should have an update_gapps.zip folder in C:\gapps2zip. Put it on your SD card, make a NANDroid backup, and flash after flashing an AOSP (Android Open Source Project) build that doesn't include the Google Apps.
Credits
Cyanogen for his hard work and dedication
Maxisma for a similar script on which this is based
Google for their ingenious ideas (although their legal department can be a pain)
Everyone who is willing to test this script out
Everyone else xD
Redistribution
Feel free to redistribute the archive wherever you like, but please give me credit along with Maxisma and do not modify the archive in any way.
Great job unk!
amgupt01 said:
GApps2zip - Created by Ankush Gupta (twitter.com/unkzdomain and unkzdomain.com)
This script makes an update.zip file that only contains the Google Apps from the HTC release of the 1.5 firmware upgrade for the ADP 1. This update.zip should be flashable on any build and it should work without a problem, but since I'm just a n00b sophomore in highschool, I am naturally poor and can't guarantee anything.
Because there are already a few alternatives to this for Linux and the majority of Android users use Windows, I decided to make this a Windows-only batch script.
You MUST have the Java Runtime Environment installed in order to run this script! The signing utility requires Java and you won't be able to flash an unsigned update.
This script does NOT work on a build that includes the new market as there are some incompatibilities with the files for it and the ones provided by HTC (namely the MarketUpdater.apk for the new market). This is pretty much doesn't matter however, because all AOSP builds will not include ANY Android market anyways.
INSTRUCTIONS
1) Google for the file "signed-dream_devphone_userdebug-img-150275.zip" (It should be on the HTC support page for the ADP 1, but it wont be the first result in Google)
2) If you haven't already, unzip the entire contents of this zip file into a directory. For sake of simplification, I am assuming it is unzipped to C:\gapps2zip
3) Place the "signed-dream_devphone_userdebug-img-150275.zip" file in the same directory as the GApps2zip.bat file (C:\gapps2zip) and DON'T rename it.
4) Open up a command prompt window (Hit Windows + R, type in CMD, then click OK)
5) cd to the directory in which the GApps2zip.bat file, utils directory and the signed-dream_devphone_userdebug-img-150275.zip file. For example:
Code:
cd C:\gapps2zip
6)Type in "GApps2zip.bat" (without the quotes) and hit enter. Watch and wait.
7) If all goes well, you should have an update_gapps.zip folder in C:\gapps2zip. Put it on your SD card, make a NANDroid backup, and flash after flashing an AOSP (Android Open Source Project) build that doesn't include the Google Apps.
Credits
Cyanogen for his hard work and dedication
Maxisma for a similar script on which this is based
Google for their ingenious ideas (although their legal department can be a pain)
Everyone who is willing to test this script out
Everyone else xD
Redistribution
Feel free to redistribute the archive wherever you like, but please give me credit along with Maxisma and do not modify the archive in any way.
Click to expand...
Click to collapse
when it asks u to replace system.img, do you click yes or no?
Looks interesting ill test it out later
Guyver75 said:
when it asks u to replace system.img, do you click yes or no?
Click to expand...
Click to collapse
You click Yes. You shouldnt have extracted the zip though, but it won't make a difference anyways.
Looks interesting ill test it out later
amgupt01 said:
You click Yes. You shouldnt have extracted the zip though, but it won't make a difference anyways.
Click to expand...
Click to collapse
oh ok, oops. i clicked no. guess ill have to redo it
ok trying to understand this. From what i get is you download, Lets say cm 4.2 without google (made up rom dont go looking for it)
then you flash that to are phone.
next when flash update_gapps.zip
Then we will have a cm rom with google apks?
And in returns the update_gapps is kinda like a theme only adding the needed files?
xile6 said:
ok trying to understand this. From what i get is you download, Lets say cm 4.2 without google (made up rom dont go looking for it)
then you flash that to are phone.
next when flash update_gapps.zip
Then we will have a cm rom with google apks?
And in returns the update_gapps is kinda like a theme only adding the needed files?
Click to expand...
Click to collapse
Exactly. The only thing is that since this uses an official, legal source, it doesn't include the new market and stuff...
Ok cool but once 1.6 adp1 is out we will have to update the script and do this again?
amgupt01 said:
This script makes an update.zip file that only contains the Google Apps from the HTC release of the 1.5 firmware upgrade for the ADP 1.
Click to expand...
Click to collapse
I applaud your efforts to help the community. Many thanks.
For those who think this is proof modding and this community will live on, think again. What he's doing aids and abets violation of Goog's rights. This thread will be locked and the links taken down. Welcome to the new world of Android.
xile6 said:
Ok cool but once 1.6 adp1 is out we will have to update the script and do this again?
Click to expand...
Click to collapse
Well, provided that HTC distributes ADP 1.6 the same way as they are 1.5 and that the file dependencies for closed-source apps are similar, we could just reuse this same script with maybe a few minor modifications.
ytj87 said:
I applaud your efforts to help the community. Many thanks.
For those who think this is proof modding and this community will live on, think again. What he's doing aids and abets violation of Goog's rights. This thread will be locked and the links taken down. Welcome to the new world of Android.
Click to expand...
Click to collapse
How does it aid and abet to violations of Google's rights? I am basically linking to an official mirror (HTC) that is licensed by Google to distribute the files.
@ amgupt01
Thanx now all we got to do is let the builds continue.
great job mr. sophomore, you should get together with cyanogen on this although i'm sure he's probably going to do something similar.
is it safe to sign in to google with the newly created update_gapps2zip?
amgupt01 said:
How does it aid and abet to violations of Google's rights? I am basically linking to an official mirror (HTC) that is licensed by Google to distribute the files.
Click to expand...
Click to collapse
I think the issue is that Google doesnt want its closed source apps put on non google-experience phones. This guy's method allows just that.
Cyanogen's method (from what I can gather) is to run an app on your phone that backs up the apps that you have on your phone (presumably licensed copies that you acquired when you purchased your phone, or during an OTA update), and then restores them after you run his barebones ROM. In this manner, you are only using backed up copies of software you are entitled to use.
I read somewhere (maybe in Google's C&D? I'm to lazy to go look) that Google does not allow these applications to be copied or extracted or something to that affect.
Honestly, why on earth would we expect them to react any differently?! This is a growing pain. We will all be better for it when its passed.
Here's how I'm planning on riding this out:
1. When Cyanogen releases 4.2, I will unroot my phone, and get the most recent OTA update from Tmobile.
1. Install Cyanogen's 4.2 ROM, using whatever method of installation is required to back up my closed source applications and restore them.
2. Continue to update Cyanogens ROMs this way until we discover that our old closed source apps are no longer compatible with our state of the art ROM.
3. Begin to seek out alternative apps, or check progress of the new "Open Android Alliance" or whatever those guys are calling themselves since this whole fiasco started, to see how feasible that option is.
4. Buy a new phone? I mean, how far down the road are we talking here?! And yes, when the time comes, assuming Google doesn't do something completely draconian that makes us pine for the good old days when they sent a C&D to Cyanogen, it will be another Android phone (subsequently rooted, of course)
I don't really see another legal option.
Code:
Cyanogen on twitter
So I think I've come up with a solution that should work and not violate any licenses. Just need to polish it up a bit.about 14 hours ago from twidroid
Thanks for this script.. i am amazed of how fast the community is getting up from the C&D .... Open Android Alliance is kicking off, Maxima is already out with a NO Google ROM, and this script, to get google's apps... wonderful...
amgupt01 said:
How does it aid and abet to violations of Google's rights? I am basically linking to an official mirror (HTC) that is licensed by Google to distribute the files.
Click to expand...
Click to collapse
amg, I'm worried on two fronts.
1, HTC is redist'ing Goog bits. They may very well get a c&d. I can't imagine HTC has a license to freely distribute them to anyone and everyone. I have to believe the license is for use on HTC hardware, not any user worldwide as download and extraction would allow.
2, you are aiding in the grabbing of those bits that a user may not have license to.
Granted, I know the vast majority of us have license. But there a few non-Goog experience phone owners around here. I suspect the mods will lock down.
But again... I think that would be wrong. We have license to the bits and grabbing them from HTC is not a violation IMO. But we'll see.
Thank you.
amg,
From the HTC license page when you download:
-----
You may not copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the Google Software or any part of the Google Software. You may only load the Google Software onto the Android Developer Phone 1, and except in conjunction with third party software that makes up the Android system image, you may not combine any part of the Google Software with other software, or distribute any software or device incorporating a part of the Google Software.
-----
So it's clear this is illegal. I think HTC will have to pull this down sooner or later as widespread extraction starts.
btw, I think you're fine. HTC will hear from Goog and this thread will be locked. But otherwise don't worry.
Hi,
Some people on the forum probably noticed it already before me, but tweets from Cyanogen and JBQ brought it to my attention that the official Android 1.6 system images for the ADP1 are now available for download from HTC:
http://developer.htc.com/adp.html
I haven't installed them yet because my unofficial Cyanogen build is probably better than those in a number of ways ;-) But I did download them.
Also, these are probably required to build a real & working Donut 1.6 build from the AOSP tree.
Cheers everyone, and enjoy!
--Tim
Just wondering couple things:
1. Does it have Google Apps?
2. Do you loose root if you install this?
3. Does it mess-up recovery image?
So did anyone try it yet?
Hi Karolis,
I haven't checked the contents of the images but I expect them to have the Google apps. The 1.5 images from the same site contained them, as far as I know.
Whether or not it messes up the recovery image depends on the method of installation you choose, but you can always put back the recovery image of your choice on your ADP1.
I don't know about losing root access or not. I've heard people claim that it depends on your recovery image used. It will not include the SuperUser application but you can install that manually.
Cheers,
--Tim
HTC is an authorized Google distributer I guess:
# Use of the Google Software by You
1. You agree to use the Google Software only for purposes that are permitted by (a) this License Agreement and (b) any applicable law, regulation or generally accepted practices or guidelines in the relevant jurisdictions (including any laws regarding the export of data or software to and from the United States or other relevant countries).
Click to expand...
Click to collapse
I'm going to flash just the system image and see how it goes...
Didn't wipe, going from CM 4.1.11.1 to 1.6 - boot looped.
Finally got back to recovery (Cyanogen Recovery gone!) and wiped cache + user data, and at least got it to boot. Phew!
Better get Cyanogen's recovery back pronto, so I can restore my nandroid backup.
/Mats
dude.... dont use the OTA, use fastboot and fastboot flash boot and system and reboot -w. The reason it requires a wipe is because of the differences in frameworks, apps, dependencies, ramdisks, etc.
I was waiting for this, this is going to be my default now. I don't like all the stuff Cyanogen does to builds, I preffer the official ADP builds 1000's times more.
---edit----
I flashed it right away and now I'm confused. It's 1.6 alright, but the build is different from previous ADP builds, no dev tools or spare parts or anything else. This is almost exactly what you'd probably get from a stock 1.6 build, weird...
BTW, you don't lose root with this, ADP builds are meant to be rooted, you know?
can someone confirm if you lose cyanogen's recovery image?
···
这个还不错··希望走点出update包····but··我最期待cm 4.2···
Agh someone plz post a 32a version
Gosh, what a mess. After finally getting CM recovery back in, I went for a nandroid restore, but instead made a nandroid backup, overwriting my precious backup of my phone as it was before embarking on this 1.6 adventure. Well, after reinstalling CM 4.1.11.1 (hush - I had a backup on my SD card!) at least I got all my apps back.
Why must I dive into stuff like this when I'm in a rush and really don't have the time for it?
/Mats
I don't understand. Why such interest in this build when it specifically states this is for ADP (Android Development Phones) ONLY!
If you do not OWN an ADP1, then please, this thread has NOTHING for you of interest.
marty22877 said:
can someone confirm if you lose cyanogen's recovery image?
Click to expand...
Click to collapse
You wont loose it if your flash the new system and boot partitions via fastboot. Any of the Apps 2 SD stuff won't work though.
elzee said:
I don't understand. Why such interest in this build when it specifically states this is for ADP (Android Development Phones) ONLY!
If you do not OWN an ADP1, then please, this thread has NOTHING for you of interest.
Click to expand...
Click to collapse
????
Aaaanyway... I noticed this build doesn't let you su (wrong uid for the su binary), but that can be fixed easily, just pull su and Superuser.apk from another build, boot your phone into recovery, and push su to /system/bin and Superuser.apk to /system/app, then chmod 4755 /system/bin/su and reboot.
---edit--
you might also want to rm /system/xbin/su, but I don't know if it's really necessary or not. Gonna try it.
ok, removing xbin/su did nothing apparently, so it's safe. Keep in mind though that the stock boot.img is doesn't allow you to adb remount, but you can still adb shell, then su, and then remount manually (mount -o rw,remount /system). We just need to change ro.secure in it and we're good to go.
Using fastboot to only flash boot and system worked perfectly fine for me.
Very nice and clean.
Apps2sd can still be had if you want to, just do it the manual way (creating symlinks).
Pushing the xda versions of Launcher and Messaging makes the phone very, very nice - and the only things that I feel I'm missing is the userinit.sh and compcache really....I never really noticed/cared too much about the BFS.
Pretty nice build to be honest....
elzee said:
I don't understand. Why such interest in this build when it specifically states this is for ADP (Android Development Phones) ONLY!
If you do not OWN an ADP1, then please, this thread has NOTHING for you of interest.
Click to expand...
Click to collapse
Because the G1 and ADP1 are both identical Dream handsets? And people want an official donut, rather than 1.5 with many donut features hacked in?
just wondering, will this work with rooted Dream Phones???
bootloader
i'm getting error message updating from 1.5 adp crc1:
Bootloader Version...: 1.33.2005
Baseband Version.....: 2.22.19.26I
Serial Number........: HT847GZ00498
--------------------------------------------
checking product... OKAY
checking serialno... OKAY
checking version-bootloader... FAILED
Device version-bootloader is '1.33.2005'.
Update requires '1.33.2004' or '1.33.0004' or '0.95.3000' or '0.95.0000'.
Click to expand...
Click to collapse
i have a adp phone.
tried to roll back to stock 1.5 img or ota, same issue, is someone had this issue?
@ anyone who tried this. Which build number is this? Is it newer than 1.6_r1 (DRC79) or should I keep building the experiemental tree?
Just throwing an idea out there, and since it's for developers (specifically people who make their own recovery images) I assume this is the right section.
Since we have 'control' over the recovery image on our phones, would it not be possible to add a little script to an update.zip that a suitably modified recovery image could extract and run to interactively prompt the user for various Rom options? I'm thinking specifically of kernel choices, but it could be extended to almost anything that needs to be done prior to booting the installed image.
Imagine installing a rom, and during the install you got a little menu like this:
1: RamHack, BFS Kernel
2: RamHack, CFS Kernel
3: No-RamHack, BFS....
etc...
inefficient, it adds extra baggage to rom, and more things can go wrong. what would you rather downlaod a 90mb file or a 110 mb file.
Which would you rather download, one 110MB ROM or 2 90MB ROMS?
I'm pretty sure there's more than a few people who'll download different variations of the same ROM so they can see which is faster, how much easier would it be to just download one thing and then choose which options you want in there without downloading anything else.
I believe it is entirely possible. As a matter of fact, I was working on a ROM project that would have an interactive installer from the update.zip that would selectively install different features, apps, customization, themes, etc., based on the recovery menu application. It would use a lot of the /cache for temp space, though, as the installer application and its resources and configuration file, and later, the necessary parts of the ROM itself, would need to be unzipped before the install can run, if I recall correctly.
Does anyone have a good link to a reference for the command syntax for the /META-INF/com/google/android/update-script file? I'll go search for it in a few moments myself. I could probably make a simple ROM installer that chooses between ROM X and ROM Y based on a key input, as a proof of concept. I'll test it myself, I don't really mind half-bricking my device for science. (As long as I don't need to touch the SPL/Radio, that is.)
Update: Some creative searching finds me this:
JesusFreke said:
Assuming you mean update-script in an update.zip update, you will need to either look at existing update-script files for an example of the syntax, or look at the source of the recovery program in the android source
Click to expand...
Click to collapse
There's also a "make-update-script.c" file I'm seeing here and there, I'm trying to find the file in the Android source.
Update 2: From install.c at donut from cyanogen's android_bootable_recovery:
Code:
#define ASSUMED_UPDATE_SCRIPT_NAME "META-INF/com/google/android/update-script"
#define ASSUMED_UPDATE_BINARY_NAME "META-INF/com/google/android/update-binary"
and in commands.c, toward the bottom at register_update_commands is all the commands defined, and above that are all the functions they carry out.
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
markolo25 said:
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
Click to expand...
Click to collapse
Well, on the 32B platform with the Death SPL (my phone) we have the following partitions of the internal NAND memory (mtdblock*) from the df and mount command:
NAND 3: /system 92160kb - OS partition, static and read-only
NAND 5: /data 91904kb - User, system config, app config, and apps (without a2sd)
NAND 4: /cache 30720kb - OTA cache, Recovery/update config and temp
And I'd assume NAND 1 and 2 are the kernel, ramdisk, and bootloader config.
So the ROM wouldn't exceed 92MB installed (most leave some room in /system for hacks and updates). And the update process doesn't ever really "flash", per se; it just formats, copies files, and sets permissions and initialization configs, like Windows or Mac.
So the files that are common to the different ROMs being packaged don't need to be duplicated, only the ones that are changed (like a boot.img, or 32A/B compatibility, or different apps). The update script and chooser menu will decide which files to copy. Meaning the ROM package in and of itself shouldn't really need to exceed 128MB, even if choosing from a wide variety of platforms. And upon installation, the system might take less than 32 MB.
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Deicist said:
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Click to expand...
Click to collapse
I could download them all, and find the differences of each. It would be cool if a ROM like this were available in a single download, from which you would choose the content from the device before flashing.
Also, inspired by talking about this, I wrote up a guide on the update-script in the package file. It's still not finished, but it'll be the only guide available for that syntax yet (trust me, I couldn't find one myself ). Link's in my sig.
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
how big of a ROM are you thinking about?
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
jmhalder said:
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
Click to expand...
Click to collapse
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
domenukk said:
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
Click to expand...
Click to collapse
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
TylTru said:
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
Click to expand...
Click to collapse
You could just have flashed the original rom without wipe.
Would be a step forward if you could simply put roms and additional files in folders... maybe even whole zip files containing some updates and an xml like file to describe them. This would guarantee compatibility with earlier boot images (just unpack the updates in the zip). Tar might work better than zip as it is not compressed thus faster afaik.
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
TylTru said:
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
Click to expand...
Click to collapse
This is pretty awesome. I was going to say, we could easily run bash scripts but this is so much better.
This needs to be merged with both Amon_ra's recovery and the new 2.x based recovery...
Hi,
I have seen a lot of posts and threads, but was unable to find the procedure to build the source code for the device.
I am a junior android developer and I would like to learn from the experts here.
I have got the latest gingerbread source code from git repo and I would like to make my own changes to the code, add new icons, build it and then flash onto my Nexus S.
Please let me know the detailed procedure.
The procedure is documented on the google homepage.
You can start here:
source.android.com/source/download.html
Thanks for the reply.
I tried all this and had built the code successfully too. But when am flashing with -w flashall option, its saying radio must be below I9020XXKB3 version.
I tried to flash individually boot.img and system.img, but lost root and also google apps are not present ( like maps, navigation.. ).
superatmos said:
I tried all this and had built the code successfully too. But when am flashing with -w flashall option, its saying radio must be below I9020XXKB3 version.
Click to expand...
Click to collapse
Can't really help you here. AFAIK KB3 is the latest radio available.
I don't know, why the latest android version shouldn't support it.
superatmos said:
I tried to flash individually boot.img and system.img, but lost root and also google apps are not present ( like maps, navigation.. ).
Click to expand...
Click to collapse
boot.img is the kernel and initramfs.
system.img is the root partition.
The radio is another partition again, AFAIK (again).
Google Apps are not present, because they are not part of the Android open source project, but are closed source.
They are licensed by Google to device manufacturers under some conditions.
One condition is to conform to the android compatibility document (hxxp://source.android.com/compatibility/index.html).
You can find the google apps around the internet somewhere though. I remember seeing them for download on the cyanogenmod homepage.
EDIT: Root is gone because it is a modification of the system (in system.img) in the first place. Unless you integrate it into the build process it won't be there.
Warning/disclaimer: This thread is intended for those who already know how to compile a kernel and have a working knowledge of Linux and its derivatives. There shouldn't be a great deal of risk involved, but you are responsible for what happens if you decide to follow these instructions.
Polite request: Please don't post replies to this thread that aren't of a technical nature directly related to compiling, modifying, or testing the kernel.
Introduction:
It appears as if Lenovo have released a buildable and bootable kernel source. I've done some preliminary testing with it. However, it would be better if we could get lots of people building and running the kernel, so that we can spot any remaining problems. This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Kernel source:
Get it from the Github repository at: https://github.com/gmarkall/lenovo_a1_07_kernel
Toolchain:
The Makefile seems to suggest that Codesourcery 2010q1 has been used by Lenovo to compile the kernel. Get it from https://sourcery.mentor.com/sgpp/lite/arm/portal/release1293, and make sure that the arm-none-linux-gnueabi-* binaries are on your path.
Building the source:
You may wish to edit the Makefile around line 192 to set CROSS_COMPILE=arm-none-linux-gnueabi- instead of the hardcoded path that is the default.
Then, to build the kernel:
Code:
make distclean
make a1_07_defconfig
make uImage
Booting the kernel
Normally, Android devices have two boot images that consist of a kernel and a ramdisk. One boot image is for the recovery, and the other is for the Android system. This makes it safe to flash a new boot image containing an untested kernel for the Android system, since the recovery can always boot up using the other boot image. However, the A1, by some bad design decision, only has one kernel - the bootloader always loads the same kernel, and just loads a different ramdisk depending whether it is to boot into recovery or system. As a result, it is not safe to flash a kernel to your A1 unless it's already been tested, since a bad kernel will make it impossible to boot from the internal memory, and you'll need a bootable SD card.
The solution to this problem is to make a bootable SD card for loading the kernel and ramdisk from. A bootable SD card consists of two partitions:
* A small bootable VFAT partition, that holds the X-Loader (MLO), U-Boot (u-boot.bin) and the kernel (uImage).
* An ext2 partition that holds the root filesystem.
In order to create a bootable SD card, use the omap3-mkcard.sh script that is attached below. To invoke it for making /dev/mmcblk0 a bootable SD card:
Code:
sudo omap3-mkcard.sh /dev/mmcblk0
You may need to hack the script if your SD card device isn't a /dev/mmcblk* one, since the script searches for partitions denoted "p1" and "p2" - this may need changing to just "1" and "2" respectively (thanks Xbdesign and Brancaleone for this).
This will create the necessary partitions, set the bootable flag, and format them. You will then need to mount the first partition (e.g. /dev/mmcblk0p1), and copy MLO and u-boot.bin to it (also linked below). Then, copy the uImage that you built from your kernel tree, which will be located in /arch/arm/boot. You can now unmount this partition.
Next, mount the second partition (e.g. /dev/mmcblk0p2). This will need to contain the same set of files that the initial ramdisk contains. There are two different ramdisks that you might want to use - one is from the Cyanogenmod 7 build, and the other one is from the stock system. Download links for these are also below. To extract the ramdisk, copy it onto the SD card second partition, then run the following commands (assuming the ramdisk is called ramdisk.ub):
Code:
dd if=ramdisk.ub of=ramdisk.img.gz bs=64 skip=1 # Strip off the U-Boot header
gunzip ramdisk.img.gz # Unzip
sudo cpio -idmv < ramdisk.img # Extract the cpio archive
Then, unmount the second partition of the SD card.
You should now be able to remove the SD card and insert it into your A1. Power down the A1 and power up again, and it should hopefully boot from the SD card and load your kernel. If it's booted from the SD card and loaded your kernel, you should be able to see that it was compiled on your host by looking in Settings -> About Phone -> Kernel Version.
Troubleshooting:
This is not a comprehensive guide, just a few pointers to where a problem might be - please post replies to the thread to get troubleshooting suggestions.
System boots up, but is not running my kernel - it didn't boot from the SD card. If the A1 is plugged into the charger/USB, you sometimes need to reboot multiple times before it boots off the SD card (I think it doesn't always turn off fully when the charger is plugged in).
The static Lenovo logo flashes up over and over again - it's booted from the SD card, but didn't manage to load your kernel
The static Lenovo logo comes up and stays there/goes to a black screen - it's probably loaded your kernel and mounted the root file system, but failed to mount /system. Try running adb shell to see what happens. If you get something like
Code:
/system/bin/sh: no such file or directory
then your kernel is running but /system isn't mounted.
IRC Channel
Join #ideapad-a1 on irc.freenode.net to discuss the kernel and other A1 development-related topics!
Download Links:
MLO
u-boot.bin
omap3-mkcard.sh
Ramdisk for Cyanogenmod 7
Ramdisk for ROW 2643 stock release
I've added the two ramdisks that I suspect will be most common - if you need another ramdisk, you'll have to extract it from an OTA.
Also, I compiled a tun.ko - www.doc.ic.ac.uk/~grm08/ideapad/tun.ko
Here's a cifs.ko - http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
EDIT: AutobahnA1 and infraredevans have confirmed that tun.ko works on ROW_2643.
EDIT 2/3: Please test out cifs.ko! (It doesn't work - it needs slow-work.ko. Will get that done when I can. Thanks to Ilikecokethree on the Lenovo forums for pointing that one out).
你懂中文吗，大神！
我是中国人 关注你的帖子很久了，我不懂英文，用翻译软件看的大概，我们这里很多人支持你，都在用你的rom 很棒！比联想官方的好多了，谢谢！
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong? Thank you very much.
PS: I'm a chinese too, and my English is not good either
gmarkall said:
This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Click to expand...
Click to collapse
Please do not forget to try the WiFi-based geolocation, which is also missing!
I wish I had the knowledge to work on it myself but I am far from taking over such tasks...do not have the slightest idea about how these things work.
Good luck and please keep us informed!
geoponer said:
Please do not forget to try the WiFi-based geolocation, which is also missing!
Click to expand...
Click to collapse
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Also, it's working in CM7.
hohoxu_hao115 said:
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong?
Click to expand...
Click to collapse
Sounds like it's booting from eMMC instead.
Can you post the partition table of the SD card as listed by fdisk, and also a directory listing of each of the two partitions? I ask this to confirm what's happened - seems like you're the first person to follow these instructions, and it's quite possible I made a mistake somewhere.
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
@Graham: I plan to install the CM7 that you have been working on (with the feedback from other users - I keep an eye on that thread!) but since I use my A1 for professional purposes as well, I would like to make sure that everything is working fine before moving to CM7. Apologies for not being able to contribute to the beta testing of CM7 but I am really looking forward to seeing a version based on the source code provided by Lenovo, which I think will lead to a more stable version of your CM7. I cannot thank you enough for taking the time to work on this, really!
geoponer said:
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
Click to expand...
Click to collapse
I think that whether it works in CM7 or not, it almost certainly isn't a kernel issue. I'll test it by signing up for Foursquare and give it a try out on CM7 to see if it works later on. Will post my findings in the CM7 thread.
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
dusko_m said:
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
Click to expand...
Click to collapse
I do want to implement something that's pretty much as you describe. My biggest motivation is that it's currently not safe to flash a kernel since you can break both system and recovery that way in one go - I really want to make the boot process more robust.
gmarkall said:
Also, I compiled a tun.ko - tun.ko
I haven't tested it yet - is anyone able to try it please?
Click to expand...
Click to collapse
The module loaded without a problem on my 2643_ROW Kernel. Installed "Rooted AnyConnect" from the "Play Place". Now I can connect to my company VPN.
gmarkall: YOU ROCK! THANK YOU!!!
tun.ko
Graham
The tun.ko module works perfectly with openvpn on 2643_ROW.
I can now access my Amahi home server,awsome.
Thanks a lot you are doing a great job.
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Cheers
Infraredevans said:
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Click to expand...
Click to collapse
I'll give it a whirl... give me a few minutes.
gmarkall said:
I'll give it a whirl... give me a few minutes.
Click to expand...
Click to collapse
Here it is: http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
To compile it I had to copy md5.h from another kernel source to fs/cifs in the kernel tree. I also had to edit init/Kconfig so that CONFIG_SLOW_WORK defaulted to yes. I configured the module with the options:
Support Legacy LANMAN servers which use weaker security
CIFS Extended attributes
CIFS POSIX attributes
and without statistics, debugging, or experimental features. Let me know if this is a suitable config - I could always tweak it and build another one.
arm-2010q1-202-arm-none-linux-gnueabi.bin
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
xbdesign said:
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
Click to expand...
Click to collapse
I did - I didn't have any problems, but my random guess about how to solve it could be to install ia32-libs. If installing that doesn't solve it, can you post a bit more detail about the problem?
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
xbdesign said:
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
Click to expand...
Click to collapse
Do you need that to run the installer? I just downloaded the tar version instead and extracted it. I saw there was an installer as well, but I thought it would be more hassle than using the tarball so I just ignored it.