yashsingh1/xdaforums huggingface dataset:
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
Good morning. Hope everyone had a good morning but if you didn't, you're about to!

V8 is almost ready!!!!!!!!!!!
[T-Mobile Samsung Galaxy S II SGH-T989] stlouisblues:
Can't wait!
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
Who's Ready? GO GET IT!!!!!!!!!!!!!!!!!!!

LINK IS LIVE!!!!!!

If you think you can get away with dirty flashing on this version, think again. This is a completely redesigned base. YOU MUST CLEAN FLASH.
[T-Mobile Samsung Galaxy S II SGH-T989] DarkAdonis:
Will flash now
[T-Mobile Samsung Galaxy S II SGH-T989] bzlik88:
.....The silence of flashing.....
[T-Mobile Samsung Galaxy S II SGH-T989] ArcticFish:
I flashed too much, but this I can't resist

Sent from my PAC-MAN SGH-T989 with KKO
[T-Mobile Samsung Galaxy S II SGH-T989] DarkAdonis:
The camera and camcorder are good! Yes!
[T-Mobile Samsung Galaxy S II SGH-T989] bzlik88:
So far....

The bad, unfriendly for 160dpi :(

The good, everything else
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
Is anyone getting an ota update notification on v8?
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
Should be OK with 160dpi. Make sure you're using nova launcher though.
[T-Mobile Samsung Galaxy S II SGH-T989] ArcticFish:
So what apps from jt does it have?

Sent from my PAC-MAN SGH-T989 with KKO
[T-Mobile Samsung Galaxy S II SGH-T989] bzlik88:
Whats wrong with holo?

But when switching to phablet mode in paranoid android settings it doesn't reboot successfully. Battery pull needed. A DPI change in ROM control is also necessary to completely change the DPI. No matter what launcher or what app I'm in, the status bar cuts the screen off a bit. It also kills the keyboard theming and layout.
[T-Mobile Samsung Galaxy S II SGH-T989] marcopolo1:
i did not get the notification but, when i open the ota application i got the message saying update available .. downloading now
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
No like when you are on v8 are you getting a notification?
[T-Mobile Samsung Galaxy S II SGH-T989] bzlik88:
I got one while on v8 but it disappeared.
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
OK. Could you do me a favor and go to the ota updater app and see what it says for version.
[T-Mobile Samsung Galaxy S II SGH-T989] ArcticFish:
That awkward moment when u browse off topic and u see tmogalaxys2 make a troll thread

Sent from my PAC-MAN SGH-T989 with KKO
[T-Mobile Samsung Galaxy S II SGH-T989] DarkAdonis:
I'm still getting it after updating.
[T-Mobile Samsung Galaxy S II SGH-T989] bzlik88:
No problem
[T-Mobile Samsung Galaxy S II SGH-T989] iwasblown:
I updated to v8 and it's asking mere to download a new update to v8 as well and although i do know what the update says i turned it off because i already have v8, great job on the ROM, i just have one question and that is how did i lose my stock theme to the Android keyboard after i changed the DPI on pa interface, and can i get it back to the frosty blue it was?
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
Thanks. I was afraid of something like this to happen. I'll fix it now. Don't update guys if you're on v8 and getting a notification. As long as it says v8 in your about phone youre good.
[T-Mobile Samsung Galaxy S II SGH-T989] Crazywhitie:
Is a Full Wipe a Must?
[T-Mobile Samsung Galaxy S II SGH-T989] bzlik88:
Unfortunately no
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
I'm afraid not. The theme is dpi dependent. I'll work on getting it multi dpi.
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
Lol. It was android88's and my idea. It was just for fun. It was pretty fun.
[T-Mobile Samsung Galaxy S II SGH-T989] ArcticFish:
So hold up for a little for the ota fix?

Sent from my PAC-MAN SGH-T989 with KKO
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
You can flash v8 through ota just don't flash v8 again when you're already on v8. If that makes sense lol.
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
Fixed OTA v8'ers shouldnt get the notification anymore.
[T-Mobile Samsung Galaxy S II SGH-T989] style154:
Is there a way to get the new aokp lock screen on this?
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
As soon as team kang makes its first 4.2 build and G2usr merges it with the PAC-Man rom
[T-Mobile Samsung Galaxy S II SGH-T989] ArcticFish:
Gs2usr recently removed paprefs from his rom cuz its closed source, he said that we have to restore or install it

Are u going to do the same or will urs just come with it?
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
Oh wow, youre right. Ill contact the head of PA and ask permission. If not, ill put it as a flashable zip or something.
[T-Mobile Samsung Galaxy S II SGH-T989] negerhab:
Hey Tmo, I have 2 sets of toggles in my status bar, how do I get rid of the black and white one?
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
I'm guessing black and white is the top set?

If so, just go to settings> system> notification drawer> and uncheck power widget.
[T-Mobile Samsung Galaxy S II SGH-T989] Dennisalex:
I just took my phone in the morning to stop the alarm and BAM!!!!! V8 UPDATE! Will flash it later Because i will test PTMR3 Rom´s.
[T-Mobile Samsung Galaxy S II SGH-T989] free2saute:
:confused::confused::confused::confused::confused::confused::confused:
[T-Mobile Samsung Galaxy S II SGH-T989] bzlik88:
OK I give up. I need help tmo.

1. Status bar thickness doesn't adjust as DPI changes. How do I make it adjust? Its still fat while its contents are small.

2. Why are my app icons not adjusting either?

I managed to get everything else worked...I think
[T-Mobile Samsung Galaxy S II SGH-T989] Project: Awesome:
The size of the status bar doesn't change. Icons will change once your using nova and set user apps dpi to 160. You have to set all the dpi changes from the pa preferences as it is the default.

I'll give you 160 dpi'ers (including me) a flashable zip that makes all this easy.
[T-Mobile Samsung Galaxy S II SGH-T989] Dennisalex:
Sorry i got no time to think just Need to flash it!
[T-Mobile Samsung Galaxy S II SGH-T989] marcopolo1:
loop

hey tmo, i followed the instructions but still get a loop boot, ( on the S) .. i downloaded the file using the ota update application, i flashed twice and nothing .. still on loop boot.

i download the v8 form op and i got aborted (bad) ..maybe a bad download i will try agin to download ..
[T-Mobile Samsung Galaxy S II SGH-T989] bzlik88:
Zip would be nice. Too tedious to change DPI.

The status bar should change, if it doesn't then this happens. Notice for example the xda app pages in the top right corner:

Everything is cut off cuz of the status bar. So what I want to know is....is it just me? Am I doing something wrong? Do u have this too? Will ur zip fix it?

Thanks man
[T-Mobile Samsung Galaxy S II SGH-T989] free2saute:
try in paranoiandroid a reset to see if it was you
[Gen9 Android Development] DragosP2010:
Any words about hdd versions?
[Gen9 Android Development] trevd:
I all depends how you want the structure it, What it would change is the mount point of the paritions directory. After that. everything is loop mounted and sitting on top of the existing structure.

mount ext4 /dev/block/mmcblk0p4 /partitions
[Gen9 Android Development] scholbert:
Great stuff!!!!

Hey trevd,

that's fantastic... i will definitely try this CWM in a few days with my custom kernel and bootloader (mountpoint will need some tweaks as well :D).

I'm very busy these days, so i gess i'll leave some longer statements to the recent developments in a few days.

Just in short... it's very pleasant to see all these open developments popping up and i really, really appreciate this kind of hacking!

Keep on your great work... you rock!!

Cheers,

scholbert
[Gen9 Android Development] letama:
Hi Trevd,

Nice job!

I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount loop@file in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.

Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.
[Gen9 Android Development] scholbert:
Hey letama,

nice to read you :highfive:

Cool stuff again...

AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.

Anyway, made some experiments with my latest u-boot port for the tablet this weekend.

I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).

There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user :p

Cheers,

scholbert
[Gen9 Android Development] trevd:
Thanks Letama + Scholbert

I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.

Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )

Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:

Thanks for the input guys!
[Gen9 Android Development] letama:
30 for init kernel ? That's plenty indeed! Cool!

Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills :)

Hummm... You're going to end with a full re-partitioning scheme with system and data if you continue this way :). Just be careful when you recreate partitions to let the empty space at the beginning of the disk untouched, instant brick ahead if you go there...

Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.

Last advice: rawfs, don't touch it :).

Anyway, the good thing with what I did on Xperia S is that you don't mess with rawfs and re-partition, it's just like flashing a very big SDE kernel from recovery with unmodfified sde firmware, that's all. If I find some time, I'll take a look to see if we can do the same thing here.
[Gen9 Android Development] trevd:
Hi

Yes I have read your previous threads on the subject which provided alot of the inspiration for the work currently at hand, It is also why I am being ultra careful around the partitions :)

I think maybe I'm just being too clever trying too pull everything back a step into the intramfs when we can just do the old switch root method method.... It's a little messy on the inside but it will get the job done!
[Gen9 Android Development] letama:
Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.
[Gen9 Android Development] trevd:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.

I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
[Gen9 Android Development] letama:
Well, it's required. It's used inside Android, it handles audio, wifi, codecs, smb...

In rawfs or initramfs ? I wouldn't add any file in rawfs, it would be difficult to do and I don't know how would behave the bootloader if it sees new files there. Initramfs you're free to do whatever you want until you reach maximum size of kernel+initramfs.
[Gen9 Android Development] scholbert:
Well kind of... while i try to stick with the MicroSD our fellow vincencb follows the omap4boot path.

He already made a port of barebox bootloader to work with this tool and pushed it to the repos.

This way you may put anything you like on the tablet's RAM by using MicroUSB for communication and file transfer.

My way is more to get a full featured u-boot and put it into a state, where it might replace stock loader.

Last step is to put it in internal eMMC... so this is also research and development for now.

Yepp that sounds like a reasonable approach.

To be even more precisely, there are 32512*1K blocks for the rawfs partition.

On my device there's ~12MB left...

Yeah, a real switch would be nice indeed... there's some unused testpoints giving us additional GPIO :cool:

Need to solder though...

Some stuff outside of system is quite useful and gives us something like a minimal linux ecosystem.

Very useful at console level... some tools seem to be used by the Android system as well.

Mmmh, letama maybe right with being very careful with this part of internal storage. If it get's corrupt you'll risk a brick (could be restored though by using external boot mechanism).

Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.

There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry :confused:

Anyway, this is a real nice project and i would really appreciate to see it pushing forward.

Take your time trevd, and again thanks a lot for contribution!!

Have a nice day,

scholbert
[Gen9 Android Development] Quinny899:
Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
[Gen9 Android Development] trevd:
Hi Quinny

There's nothing to stop us using whatever recovery we like.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary. Unfortunately my touch screen stopped working long ago so I wouldn't really benefit :D
[Gen9 Android Development] letama:
Ah, yes, but there is space reserved for each file there, what I have to figure is how much is reserved for custom file (sde kernel). I don't want to have to shift the files located after custom to make room for sde kernel , it would defeat the "no-fuss/no-risk" of the method.

Definitely. Re-partitioning is much safer if space is needed.
[Gen9 Android Development] scholbert:
This is a good keyword: The recovery binary itself!

Most tools inside the recovery are simply linked to busybox, which itself is a link to recovery executable.

In other words, we have some code responsable for the menu and framebuffer stuff and we have busybox.

The strings command gave me version 1.2.0. Now my question...

How to configure this part of code?

I'd like to enhance the busybox part.

Could you please provide a little to howto for a compiler run?

Will i need all that Android stuff installed... :confused:

I you have any clue, please point me in the right direction.

Lazy,

scholbert
[Gen9 Android Development] letama:
Yes, you need full android repo. Android Build system is messy and tightly coupled, busybox is compiled with bionic (android libc), recovery is built on top of it with few android libraries links. Isolating all this "mess" would be difficult. Except disk space required, there is no big deal in getting full android repo.

I'd suggest to take a look at this, you should do the "Prepare the Build Environment" section.

I don't know how trevd built his recovery, but what I did is create a gen9 device to get proper configuration for recovery (frame buffer config, ...). You can get mine if you want, it's a little outdated (latest cwm doesn't need a specific gfx anymore, the custom one I used has been moved to upstream for instance), but it should give you a base.

To do that, you have to create an "archos" directory in cm9/device directory, then from inside it do:

git clone git://gitorious.org/archos-ics/device-g9.git gen9

Then, you need to setup the build env once. From cm9 root, you have to do that:

. build/envsetup.sh

(it setups android build environment)

then

lunch

then choose full_gen9-eng.

(it selects device target for build)

You should have something like that:

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.0.4
TARGET_PRODUCT=full_gen9
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=IMM76L
============================================

from this point, you can compile:

make -j4 recoveryimage (change j4 with the number of parallel build you want depending on your cpu).

whole recovery fs should be in out/target/product/gen9/recovery/root, with recovery command in sbin

Last, how do you want to extend it? If you want to add custom commands, take a look at cwm bootable/recovery/extendedcommands.c, it may be easier to add stuff there than in busybox.
[Gen9 Android Development] trevd:
Hi Folks

I've decided to stay well clear of the rawfs approach mainly due to a lack of solid understanding. I've been experimenting with alternative approaches, namely using a persist property to switch between bootmodes,

The way android' init works is to group the services into classes. The class_start normally happens in "on boot" action, this is simply swapped for a property switch, which lets us start the recovery service or start the main and core classes, as a software switch this is working pretty well although I've not tested the recovery functionality yet :D It is also alot safer than playing in the rawfs!!

I'm currently working on getting 4.1.2 booting, so I've mashed my sources together but omapzoom.org is the base for repo. I replaced bootable/recovery, external/zlib with the CM10 ones and copied external/busybox from CM10 also. My device tree is from my own github. See this post for further details I'll put together a proper repo manifest at some point which will pull all the correct sources from the correct places.

There's still a bit more tweaking to do to get the build a bit smoother, currently I've hacked build/core/Makefile a bit so the ramdisk-recovery.img plays nice and I can flash it using kd_flasher from my rooted stock build. I've rebuilt a 3.0.21 kernel to support ipv6 mangling debugfs tracing both of which are required by JellyBean. I also added gzipped cpio ramdisk support, which is what the build system creates the ramdisk-recovery.img as. I chucked in /proc/config.gz support for good measure :) I've attached my 3.0.21 config for those who are interested, Although not required for recovery, the powervr kernel modules would need building aswell, these are located in the android source tree @ device/ti/proprietary-open/omap4/sgx_src there some hacking/patching to be done to get them to build but it's wondering off-topic and I'll probably do a post on it at some point.

@scholbert - All this probably doesn't make much sense at the minute, especially if you have not played around with the android sources. Also I think there's some guides knocking around XDA re: building only CWM, it might be worth digging one of those out.
[Gen9 Android Development] trevd:
Hello Again!

I've been running some tests today using a persistent property to control the switch between recovery and normal booting, This seems a pretty solid and safe approach and can be achieved solely through the init.rc. combine that with a Cyanogenmod Style Reboot Selection UI we should have a pretty painless way of switching between the 2 from a software point of view.

EDIT: Going to use the above method for now, although resetreason management in the kernel is probably a more the correct way of handling a switch.

This does leave some more research on enabling a hardware switch, the keychord driver in the linux kernel ( drivers/input/misc/keychord.c ) which looks like it was added by the android team may be worth further investigation. A couple of questions spring to mind. How early in the device bring up can we detect volume rocker presses? How early can we write to the framebuffer? I'm thinking something along the lines of options we can cycle through. The Motorola Xoom does something similar as it essentially Quad Boots between fastboot, nvflash, recovery and Android.

I've got a 4.1.2 booting up and the PowerVR drivers working, although this is far from complete, It is at a point where I am happy to put that to one side, I'm going to use a more stable rom as a base to move forward. With this in mind that leaves us ( me ) with two main tasks.

1. Rework the existing rom/compile an AOSP ICS to use the new layout, as Letama rightly points out some things outside of the /system tree are required by android, These can and should be moved into the /system and /system/vendor , where they rightly belong. I'm pretty confident that the most if not all of the binary's that are dependent on uclibc are in the archos gpl repo and can be recompiled against bionic if requried, also alot of them seem to duplicate existing android libraries/binaries. The only "problem" closed source binary I can see is /usr/bin/avos, this seems to handle archos' media functions.....Nothing that cannot be swapped out with an Open Source Alternative.This leaves abcbox, a multicall binary similar to busybox, this is statically linked, and it functions are mostly related to rom flashing. However there are some pieces of functionality which may prove useful, they are

bat - battery charger / voltage info

kd_flasher - writes sde kernel and initramfs

reboot_into - controls rebooting between archos stock, sde and recovery, probably best off being wrapped around android's standard reboot code.

led - makes the power light flash :laugh: , everybody loves blinky lights!

2. Make Recovery Work!

Recovery Is pretty much fully functional already, A small bit of internal tweaking is needed which will allow us to "blow out" sparse ext4 images and use a "classic" android combined boot.img. Both of these fiiles are created by the aosp build process and It would be nice to be able to send them to the device untouched. It would also reduce update sizes.

Easy Peasy! :highfive:
[Gen9 Android Development] trevd:
If anyone wants to help out here and you've got a knack for hacking the UI then adding a Reboot Selection Menu to the 4.0.24 UI would help massively. It needs to write either "android" or "recovery" to persist.sys.bootmode property before it reboots.

Not sure whether this can be caught by a broadcast receiver in an separate apk with the correct permissions or whether a bit of decompiling is required.