Database Users

please close thread

Development has been integrated with the new rootfs.
Please see the thread here:
http://forum.xda-developers.com/showthread.php?t=584707
New version coming soon:
Version 2.3 info:
-Newer simplified setup, whether you use a partition or not you will use the same files;
- fixed copying issues that were stopping some Donut builds from working. All builds should now work file.
-there are no additional files unlike previous builds.
- support for a data partition as well.
- supports all phones that the rootfs is supporting, kaiser vogue diamond etc.
Version 2.2 info;
updated for better data file backup naming.
updated to support donut
updated to support wifi (thanks enate for this)
Version 2 info;
On boot it will prompt you to boot the new recovery image, if you press a key it will load the recovery image, (the first boot you must do this to install the system) if not it will boot as normal.
If you have a system.sqsh on your sd card it will prompt you to install to your ext2 partition
- after installing the system it will move it to /sdcard/installedsystem/installedsystem.sqsh
- it will move your data file to /sdcard/datafilebackup/data$date
and create a new one. After the inital boot you can reboot and copy back your data file again.
There is one caveat that was pointed out to me today. Do not change systems twice in one day unless you don't care about your data. Because it creates the data file based on date it will overwright the old one.
Why not data to? Well our current data.img solution is awesome for backing it up.
What's coming;
Native support for update.zip's from the dream themes forum.
Menu support with several different usefull options for setting up android (this is proving to be tough but I'm working on it)
here it is!
http://code.google.com/p/vogue-andr...name=recoverfiles2.2.rar&can=2&q=#makechanges

mssmison said:
Hey guys, I've got something new coming for vogue android, I need 2 people with VOGUES's only to test something for me.
Requirements; linux install, vogue only, be able to provide bug reports, be serious!
pm me; I'm hoping to have testing ready by the end of the day.
Click to expand...
Click to collapse
sure
have linux and vogue pmed you. dang, guess i didnt pm you in time...

I don't know what this is, but you've sure got me curious as hell.
If you need another tester, let me know.

Well looks like I'm not in the closed beta, but I'm looking forward to this with great excitement. With the loss of Zen, it's good to have you back and active on this stuff again. This wouldn't happen to be Android running natively on our little wonder-units would it?

stickus said:
Well looks like I'm not in the closed beta, but I'm looking forward to this with great excitement. With the loss of Zen, it's good to have you back and active on this stuff again. This wouldn't happen to be Android running natively on our little wonder-units would it?
Click to expand...
Click to collapse
Technically, Android doesnt run "native" on any device. You don't have to port a device to android..just the linux kernel to get api's to work. I know your refering to booting android on our faster but much smaller enternal flash but the speed difference would be minimal and we would be confinded to smaller builds. I think it has to do with a memory limitation in android from the dalvik vm it uses. I'm not 100% sure on what im talking about but this is the impression ive had for android for a while. Please enlighten me if I have missed something..

posting in epic thread

stickus said:
Well looks like I'm not in the closed beta, but I'm looking forward to this with great excitement. With the loss of Zen, it's good to have you back and active on this stuff again. This wouldn't happen to be Android running natively on our little wonder-units would it?
Click to expand...
Click to collapse
It's been stated before and I'll state it again, the speed of the nand (internal memory) on the vogue is very slow. Making android boot from the nand would be a step backwards... What I'm hoping I've got it a step forwards

mssmison said:
It's been stated before and I'll state it again, the speed of the nand (internal memory) on the vogue is very slow. Making android boot from the nand would be a step backwards... What I'm hoping I've got it a step forwards
Click to expand...
Click to collapse
Interesting.
I really don't understand why the internal NAND is so slow. Windows Mobile runs just fine from NAND, so why would running Android from it be any different?
Alternatively, it seems that a flashable Android would be much more convenient, and permanent.
I'm very curious to know what you're working on, mssmison.

Shidell said:
Interesting.
I really don't understand why the internal NAND is so slow. Windows Mobile runs just fine from NAND, so why would running Android from it be any different?
Alternatively, it seems that a flashable Android would be much more convenient, and permanent.
I'm very curious to know what you're working on, mssmison.
Click to expand...
Click to collapse
Duel booting would a better option in my opinion..wm is just a better mini PC OS(Windows) and Android is a better phone/internet OS . This makes our devices even more versitle then phones just running android. I dont get how just having android would makes things better..since we just manually boot android instead of it booting once the phones is turned on...how about a linux bootloader that launches before wm does..and a graphical UI to choose from the two OS's

ajclai08 said:
Duel booting would a better option in my opinion..wm is just a better mini PC OS(Windows) and Android is a better phone/internet OS . This makes our devices even more versitle then phones just running android. I dont get how just having android would makes things better..since we just manually boot android instead of it booting once the phones is turned on...how about a linux bootloader that launches before wm does..and a graphical UI to choose from the two OS's
Click to expand...
Click to collapse
My understanding is that there isn't enough room to dual-boot both WinMo and Android from the NAND on the Vogue.
You could possibly put the bootloader in NAND and run WinMo and Android from storage, but that sorta defeats the purpose.

mssmison said:
It's been stated before and I'll state it again, the speed of the nand (internal memory) on the vogue is very slow. Making android boot from the nand would be a step backwards... What I'm hoping I've got it a step forwards
Click to expand...
Click to collapse
Sounds delicious.

UHHHHHH
Well this sounds cool, Nice to see that you are back......CANT WAIT......
DROID FOR LIFE

Freezell said:
Well this sounds cool, Nice to see that you are back......CANT WAIT......
DROID FOR LIFE
Click to expand...
Click to collapse
I never left.. I was just working in the background

what's the harm in saying what's being worked on?

bug666 said:
what's the harm in saying what's being worked on?
Click to expand...
Click to collapse
Suspense is just too much fun....?

If all goes well I should have something tomorrow night for everyone.

hintttttttttttt lol

mssmison said:
If all goes well I should have something tomorrow night for everyone.
Click to expand...
Click to collapse
Is it gonna require serious work to do, like flashing a rom? Or still just files on an SDCard, just in a different way?

TheKartus said:
Is it gonna require serious work to do, like flashing a rom? Or still just files on an SDCard, just in a different way?
Click to expand...
Click to collapse
..............

lol, i've been working on stuff in the background too. haha.
but anyways, i was like wtf, this is a total bs thread, then i saw your name everywhere. haha. so i guess it's not.
good to see a vogue developer still around!!
I'm working on getting another one so I can mess with the vogue again. it's a fun phone.

Will tmobile ever release eclair for the g1?

I've had a search here and on google to find any news on tmobile pushing eclair onto the g1, but cant find anything useful.
Does anyone know anything or have any provisional dates?

Assuming that G1 and myTouch are running the exact same ROM, than t-mobile will definitely release eclair (verified that the mt3g will keep on being supported with a friend working in the myTouch project team).
I don't have dates yet for that happening.

maxppp said:
I've had a search here and on google to find any news on tmobile pushing eclair onto the g1, but cant find anything useful.
Does anyone know anything or have any provisional dates?
Click to expand...
Click to collapse
I don't think they will. I have read that the eclair is too large for the G1 to hold in a stock stock state. And I'm assuming that T-Mobile will not take into account the fact that in a rooted state, there is more onboard memory for a rom of that size to be held in it.

of course the g1 will get eclair. lord knows when that will ever happen though. but if you are itchin for some *****in eclair roms.... root your phone.

Let's wait until T-Mobile actually releases eclair itself.

oshizzle1991 said:
of course the g1 will get eclair. lord knows when that will ever happen though. but if you are itchin for some *****in eclair roms.... root your phone.
Click to expand...
Click to collapse
Almost there.
But syncs being broken in one way or another and no camera not realistic for good day to day usage yet.

tazz9690 said:
I have read that the eclair is too large for the G1 to hold in a stock stock state.
Click to expand...
Click to collapse
Would you people PLEASE quit believing all the chicken little bloggers on the internet? They're mostly ALL complete morons who know nothing about anything. Their *opinions* are totally useless. Either consult an actual engineer (like me -- note: I say that it *does* fit, with tons of space to spare) or someone whose job it actually is to know *for sure* (i.e. someone who works for google or htc).
And I'm assuming that T-Mobile will not take into account the fact that in a rooted state, there is more onboard memory for a rom of that size to be held in it.
Click to expand...
Click to collapse
Uh, what? Root or not, the internal storage is IDENTICAL. Even if you use the deathspl (which you shouldn't under any circumstances), all it does is move the partition boundaries around a little -- does NOT change the overall space.
Note: It is, in fact, EASIER to fit a MUCH LARGER system image onto standard partition boundaries than it is using deathspl. On deathspl, the /cache partition is divided equally between /system and /data -- i.e., they *both* grow by 50% of the size of /cache. With stock partition boundaries, the entire /cache partition (save for a tiny amount of space to *actually* be used as cache) can be handed over as an extension of /system. That means that with stock partition boundaries, you get ~1.33 times the overall space available for the system image as you do with the deathspl. Assuming, of course, that they would ever go this way, which they won't. No matter though, since the existing /system partition is PLENTY BIG.

There is plenty of room for 2.0 on a stock g1. The problem is ram. Building direct from AOSP at the moment yields a pretty sluggish rom.
Its irrelevant anyway.. All we need is a vanilla build for the mt3g or any of the current non-hero phones and we'll have it fully working and synced on the g1 in hours.

lbcoder said:
Would you people PLEASE quit believing all the chicken little bloggers on the internet? They're mostly ALL complete morons who know nothing about anything. Their *opinions* are totally useless. Either consult an actual engineer (like me -- note: I say that it *does* fit, with tons of space to spare) or someone whose job it actually is to know *for sure* (i.e. someone who works for google or htc).
Uh, what? Root or not, the internal storage is IDENTICAL. Even if you use the deathspl (which you shouldn't under any circumstances), all it does is move the partition boundaries around a little -- does NOT change the overall space.
Note: It is, in fact, EASIER to fit a MUCH LARGER system image onto standard partition boundaries than it is using deathspl. On deathspl, the /cache partition is divided equally between /system and /data -- i.e., they *both* grow by 50% of the size of /cache. With stock partition boundaries, the entire /cache partition (save for a tiny amount of space to *actually* be used as cache) can be handed over as an extension of /system. That means that with stock partition boundaries, you get ~1.33 times the overall space available for the system image as you do with the deathspl. Assuming, of course, that they would ever go this way, which they won't. No matter though, since the existing /system partition is PLENTY BIG.
Click to expand...
Click to collapse
well you learn something new everyday. Thank you for that insight.

goldenarmZ said:
All we need is a vanilla build for the mt3g or any of the current non-hero phones and we'll have it fully working and synced on the g1 in hours.
Click to expand...
Click to collapse
And as I mentioned earlier, the MT3G will definitely get eclair - it is the job of ppl in my department to know *for sure* (not me, but they do give some info once in a while)

New Hack : data2ext possible for the vibrant?

have you guys seen this data2ext hack. if this get ported to our phones, our phones will be extremely fast. with all the good roms we have for our vibrants already.

robertd0619 said:
have you guys seen this data2ext hack. if this get ported to our phones, our phones will be extremely fast. with all the good roms we have for our vibrants already.
Click to expand...
Click to collapse
I dont beleive this will make any difference for us, if I'm reading this correctly, it simply moves the data partition to the sd card and changes the format.
You can acheive the same results on a vibrant by using a lag fix.
The universal lag fix gives you the option of changing the format of your data partition to JFS or EXT 4 and on a vibrant there is no need for A2SD as you have plenty of space for apps.
that was an interesting read though
thanks for pointing this out.

[Semi-DEV] MTD Partitions on DHD-Too large cache

Hey guys(mostly devs,would post in dev section but you know,it's not "right").
I was monitoring something that had gone haywire on my phone with OS Monitor and I found something rather odd.
The /cache partition on the Desire HD is roughly 300Mb,while ONLY almost 19Mb were used.Summing it up,it's more than 250mb of space going to waste.So I thought,especially when coming from a Desire(512mb nand anyone? ) and with all Sense 3 roms coming up,/cache could get smaller with some of the "wasted" space going to a slightly larger /system partition and mostly to a larger /data partition,which might be big enough for most,but for those of us that just forget their devices have certain limits,it would be cool.And in many cases A2SD won't be needed.
So?What do you say guys?If many of us gather we could attract developers' attention.Or at least I hope so!
Regards
Apostolis

Not possible to change partitions size so far on Desire HD. And wont be possible probably

mike1986. said:
Not possible to change partitions size so far on Desire HD. And wont be possible probably
Click to expand...
Click to collapse
Oh...And may I ask why is that so?HTC's security?If yes I think I'm a step closer to buying the Galaxy S 2 and not the Sensation...
Anyway,thanks mike!
Sent from my Desire HD using XDA App

mike1986. said:
Not possible to change partitions size so far on Desire HD. And wont be possible probably
Click to expand...
Click to collapse
It should be, it was done on the desire without even touching the bootloader, all it took was a script to modify cwm and the boot.img
Sent from my R800i using Tapatalk

AndroHero said:
It should be, it was done on the desire without even touching the bootloader, all it took was a script to modify cwm and the boot.img
Sent from my R800i using Tapatalk
Click to expand...
Click to collapse
Yep,that's what I was thinking,but the level of security on the DHD is far worse(Worse for us that is! ) than it is on the Desire.I wouldn't know,development isn't my speciality,so Mike will know better.If only you could clarify a little Mike...
Or we could contact Firerat.Isn't he the guy that started the whole MTD partition thing?

Wanna push that thing up!
Now on CM12+ i think its more interesting and four years later maybe someone knows a bit more?
Is there something new?

Encryption causing slow file read/writes

http://www.reddit.com/r/nexus6/comments/2m49w1/the_encryption_issue/
http://www.reddit.com/r/Android/comments/2m49qd/psa_android_5x_encryption_cannot_be_disabled_if/
This is super disappointing.

i'm hoping (and confident) that custom kernels will be able to disable this.

vivanshah said:
i'm hoping (and confident) that custom kernels will be able to disable this.
Click to expand...
Click to collapse
Otherwise a fresh ROM image would do it.

Skripka said:
Otherwise a fresh ROM image would do it.
Click to expand...
Click to collapse
On what basis do you say that (honest question)?
Google says
Caution: Devices upgraded to Android 5.0 and then encrypted may be returned to an unencrypted state by factory data reset. New Android 5.0 devices encrypted at first boot cannot be returned to an unencrypted state.

mk262 said:
On what basis do you say that (honest question)?
Google says
Caution: Devices upgraded to Android 5.0 and then encrypted may be returned to an unencrypted state by factory data reset. New Android 5.0 devices encrypted at first boot cannot be returned to an unencrypted state.
Click to expand...
Click to collapse
Well then... Bye bye Nexus 6....

mk262 said:
This is super disappointing.
Click to expand...
Click to collapse
Well, it is less disappointing than the file system just being slow for no reason.

hitzand said:
Well, it is less disappointing than the file system just being slow for no reason.
Click to expand...
Click to collapse
AnandTech is of the opinion that the AndroBench tools are not yet functioning properly on Lollipop. It was the AndroBench toolset that Ars used to cook up their NAND comparison.

Once developers get their hands on it, they will figure out how to disable encryption. They could possibly use a hard flash method which replaces entire sectors of the NAND with new data. Simply flashing a ROM/kernel probably won't be enough.

Skripka said:
AnandTech is of the opinion that the AndroBench tools are not yet functioning properly on Lollipop. It was the AndroBench toolset that Ars used to cook up their NAND comparison.
Click to expand...
Click to collapse
Where did you read that?

mk262 said:
Where did you read that?
Click to expand...
Click to collapse
Ars's review openly labels the ssd benches as being androbench. Anand openly comments in their review that they think the numbers from Nexus 6 are so bad and weird that they cannot be correct...and therefore Anand doesn't include ssd benches in their review

Skripka said:
Ars's review openly labels the ssd benches as being androbench. Anand openly comments in their review that they think the numbers from Nexus 6 are so bad and weird that they cannot be correct...and therefore Anand doesn't include ssd benches in their review
Click to expand...
Click to collapse
http://www.anandtech.com/comments/8687/the-nexus-6-review/429491
that's interesting

Skripka said:
AnandTech is of the opinion that the AndroBench tools are not yet functioning properly on Lollipop. It was the AndroBench toolset that Ars used to cook up their NAND comparison.
Click to expand...
Click to collapse
Benchmarks don't matter. Are found in normal use the phone is slower than a N5, which is what a normal user will experience. That's what's so bad.
Also, encryption has nothing to do with this. You can enable encryption on Windows and it barely slows down disk access, if you have a modern cpu. The Nexus 6 chipset is plenty fast, so the slowdown is due to flash memory not being fast enough.

ECrispy said:
Benchmarks don't matter. Are found in normal use the phone is slower than a N5, which is what a normal user will experience. That's what's so bad.
Also, encryption has nothing to do with this. You can enable encryption on Windows and it barely slows down disk access, if you have a modern cpu. The Nexus 6 chipset is plenty fast, so the slowdown is due to flash memory not being fast enough.
Click to expand...
Click to collapse
Face palm...your modern desktop CPU has dedicated encryption instructions.

Skripka said:
Face palm...your modern desktop CPU has dedicated encryption instructions.
Click to expand...
Click to collapse
I'm not sure if the 805 has AES support, I know ARM v8 does. Regardless, since its enabled by default in L, it will hurt users.

ECrispy said:
Benchmarks don't matter. Are found in normal use the phone is slower than a N5, which is what a normal user will experience. That's what's so bad.
Also, encryption has nothing to do with this. You can enable encryption on Windows and it barely slows down disk access, if you have a modern cpu. The Nexus 6 chipset is plenty fast, so the slowdown is due to flash memory not being fast enough.
Click to expand...
Click to collapse
Wrong

ECrispy said:
I'm not sure if the 805 has AES support, I know ARM v8 does. Regardless, since its enabled by default in L, it will hurt users.
Click to expand...
Click to collapse
ARM v8 does.
805 is v7 and does not.

In which case encrypting everything by default is a bad decision. No one wants a phone slower than a N5. Did Ars get a bad unit? They are highly respected.

mk262 said:
On what basis do you say that (honest question)?
Google says
Caution: Devices upgraded to Android 5.0 and then encrypted may be returned to an unencrypted state by factory data reset. New Android 5.0 devices encrypted at first boot cannot be returned to an unencrypted state.
Click to expand...
Click to collapse
Is it possible to unencrypt things before first boot? That line has me a lil confused...

kinfolk248 said:
Is it possible to unencrypt things before first boot? That line has me a lil confused...
Click to expand...
Click to collapse
Its just a software flag that tells the firstboot process to encrypt the phone. It is described here: https://source.android.com/devices/tech/encryption/
*** quite trivial to disable.
More: Its just a parameter in the fstab, which is a plain text file that describes to vold, what to mount where. Changing the flag from forceencrypt to encryptable fixes it. Note that this file is in the root fs, which means that the boot image needs to be unpacked and repacked to modify it.
More2: They're doing it on Nexus 9, with apparently very positive results.... http://forum.xda-developers.com/nex...llipopalooza-flounder-volantis-t2933831/page2

doitright said:
Its just a software flag that tells the firstboot process to encrypt the phone. It is described here: https://source.android.com/devices/tech/encryption/
*** quite trivial to disable.
More: Its just a parameter in the fstab, which is a plain text file that describes to vold, what to mount where. Changing the flag from forceencrypt to encryptable fixes it. Note that this file is in the root fs, which means that the boot image needs to be unpacked and repacked to modify it.
More2: They're doing it on Nexus 9, with apparently very positive results.... http://forum.xda-developers.com/nex...llipopalooza-flounder-volantis-t2933831/page2
Click to expand...
Click to collapse
smh I need the hots wings and beer translation of that lol