Related
not sure if any body thought of this what if chefs let users to sign their names addresses and finger print scan in the rom
1st will be thief deterent
2nd good hearted will return it if found
3rda phone will be a personal thing,chefs can leave their name somewhere for the smell and taste fo thier cooking
I'd think Chefs should also put a file in the \windows directory called release_notes with their ROM name and a forum link to their ROM thread.
Can't say how many times I've forgotten who's I've got flashed at any given time.
First, most chef's already put their name in the rom in one or more places, second , if you are using one of Alex's rom's used the kitchen & you can put whatever you want in it. Third, if somebody decent finds the device, your name & etc. is already in device owner info or can be looked up by your carrier with the serial or esn. Finally, if anyone else finds your device , it will take them all of 10 minutes to use Google & figure out how to flash a new rom. You could change the device ID to something nonexistent to make it harder to flash, but that's something better worked out by you & no Chef is gonna want to do that for every single person, not to metion that if he did, the thief would google & figure it out.
There is always ways around things, just ask AT&T, HTC & everybody at XDA
GSLEON3 said:
First, most chef's already put their name in the rom in one or more places, second , if you are using one of Alex's rom's used the kitchen & you can put whatever you want in it. Third, if somebody decent finds the device, your name & etc. is already in device owner info or can be looked up by your carrier with the serial or esn. Finally, if anyone else finds your device , it will take them all of 10 minutes to use Google & figure out how to flash a new rom. You could change the device ID to something nonexistent to make it harder to flash, but that's something better worked out by you & no Chef is gonna want to do that for every single person, not to metion that if he did, the thief would google & figure it out.
There is always ways around things, just ask AT&T, HTC & everybody at XDA
Click to expand...
Click to collapse
1st the whole idea is not about the phone getting lost rather than personlizing it ,to google or change that is why i said chefs should make it possible to ingrave it in the roms thiefs if they know all that they are nottheifs they won't find time to steal they will be cooking for us
actually, for anti-theft, I was thinking of a kit...
1) modified SPL; requires non-standard password and a signed NBH using your own custom certificate
2) OS is locked down with a trusted certificate of your own in the store so SSPL won't run at all... unless you sign it with your certificate
3) program that checks the SIMcard IMSI; if it changes then it sends an SMS to another number.
now... there are a few practical issues with 2) because it makes installing new apps a pain in the arse since they all need to be signed, so maybe a way of buggering up SSPL would be better.
ras said:
1st the whole idea is not about the phone getting lost rather than personlizing it ,to google or change that is why i said chefs should make it possible to ingrave it in the roms thiefs if they know all that they are nottheifs they won't find time to steal they will be cooking for us
Click to expand...
Click to collapse
A Chef that makes ROMs used by thousands is not gonna want to customize or personalize each one for every user. That said, with a donation, there are many that might consider it for you. Of course, you can always use a base ROM & the Kitchen to do it yourself. I do this.
Also, you can use provisioning xml's to customize or personalize them on a basic level using UC. Read Sleuth's thread on UC (User Customization).
@ Olipro, I really like the idea's 1 & 3. I have played a bit with CID locking to an imagined CID & with false Model ID's but of course while you then can't flash a ROM that's not customized to match, you could bypass it with SSPL, making it pointless against anyone half competent.
Your solution 1 & 3 would almost have to go hand in hand, having the password & a way to keep SSPL from jumping the password measures. Something like this, in conjunction with WIMP & UC in ROM, would be a great tool for security. Very Interesting indeed.
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
I do my best
I do my best ... with the "limited space" we're given for Thread Titles on the forum.
~enom~
I support this though I find it unnecessary. The new beginner user will most likely READ atleast the first post of the thread and they will know what the ROM is based off of. The end user will of course know to read the thread before doing any flashing of any kind so organizing mod rom versioning isn't a necessity. It's convienent but not necessary
I support this because it would make ROM catalogs easier to build, which would benefit the whole community.
why not just post what android version the rom is based on in the first post. First post should always hold the most info anyways.
Since this thread hasn't been moved from the Dev section so far.
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
alritewhadeva said:
The end user will of course know to read the thread before doing any flashing of any kind
Click to expand...
Click to collapse
rofl. Funniest thing i've read all week.
+1
how about shorthand naming such as
for example:
CyanogenMod = CM-AOSP1.6r1-v4.20
If you're talking about cyanogen mod, you might want to add a couple more zeroes at the end. Anyway, I had proposed this too a while ago. I like your format, and I'll go one better; let's do cook-androidVersion-buildVersion-feature.bugfix
for example, the build I made this morning would be "jm-1.6-Donut eng.jubeh.20090930.070211-0.0"
jm is what I use for my builds (short for jubehMod)
1.6 is the current android branch (as per build.prop, no 1.6_r1 yet)
Donut eng.jubeh.20090930.070211 is the build number the compiler assigned to my build, people who work off of modding factory releases or build for dream_open are the ones who usually come up with things like CRC or DRC etc, I build for "AOSP for Dream" (it's a new "vendor" added)
first 0 is feature number, at this point my build is nothing but stock AOSP donut, no Google apps, no a2sd, no netfilter, no compcache, no bfs, just stock donut, so say I were to add a2sd, then I'd go up to 1, as I would have added one or more features (and this would be listed at the change log), basically, anything added that improves the build (and that's not a fix) is a +1 to feature
second 0 is bugfix. For example, right now my build works correctly in every sense, but I have a problem with the video camera where video is of very poor quality (real problem, I'm trying to figure it out), so say i get it fixed, then my bugfix number would go up 1, so basically, anything changed in the build strictly because it didn't work as intended is a bugfix
the last two numbers would be allowed to go past 9, so no more pressures to add .1s at the end like cyanogen was doing to prevent jumping to build # 4.2
karthikjr said:
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
yes just bench mark. its much better than benchmark pi only test the cpu really
by the way, I've been saving pretty much all roms that have been posted here (notable exceptions are haykuro's, jf's, and theduded's roms, I haven't been here THAT long) and I have them all saved on my computer separated by /cook/build/ for the Dream roms and /build/cook/ for the Hero ports. I guess I could run a quick filesystem lister and upload that list for people to see so they can sort of get an idea what mod release corresponds to what build
Here we go, I had to upload it inside a zip because of the stupid 2kb limitation on text files (this is 10kb)
lbcoder said:
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
Click to expand...
Click to collapse
................................
Hi jubeh,
Thanks, this kind of cataloging is exactly why the OP's suggestion will be helpful.
karthikjr said:
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
I'm not so sure that we do...
I think that that should be more of a "details" thing.
Maybe we can go with "name-officialversion-modversion[-custom]" (square braces mean optional). Name might be a good place to keep modelnumber (I assume you mean by that "dream", "magic", "hero", etc.),
i.e.: supercustomrom(DREAM)-1.6r1-0.0.0.0.0.0.0.1-cc_swap_a2sd
First question : Is there any accelerometer bublle level like the incredible android one for Jave J2M Samsung S5600 (Player Star) phone ? Or anyway, is there any solution to port this app from adroid to java Mobile ? I got the source jar if anyone is interested to have a look inside. It does not lauch on my mobile, certainly due to protection and very different Android OS...
Second question :
I would like to find a way for overriding the Exe/jave/games/folder to point it to my mmc sdcard ? Is there a way to do it via nv_default.ini without bricking the phone ? A better solution would be to offer both databse update search and and thos two path in ?!
I'm really not familliar with this phone OS, so if there anyone who can tell me if this system is modifiable or modable, just let me know...
Free Bonus Question : I also have a nice HTC touch P3450, wich has been succesfully updated to the latest avaible firmware. I dont know if this phone have an accelerometer ? Can anyone tell it to me ? I don't think so because none of the apps are hanging this feature, but i'm asking it also
**used Android ID Changer.. worked exactly as i needed..**
Im running vegan rom
i play a couple games that are tied into the phone( or whatever) unique id..
When i installed these games, they already act like i already have an account and will not let me login with my user(one account per device). My question is how do i change my id? If i used the id from my phone would it just act as a clone? Im fairly android literate but i cant quite figure exactly what i need to do to (or exactly explain my delima) any help or direction would be appreciated ~evil
I'm not sure how to change this, I only learned of it the other day. The Swype Beta uses the ID to register you for the beta, so if you lack one like we do then it won't work and say its unsupported. The IDs are usually unique and only appear on "phones" (devices with cell capability). However, HTC and Samsung have applied one ID to all of one device so this breaks some programs. This leads me to believe we lack the ID entirely. If you find out where the programs are looking and how to add or change the ID make sure to post the information up for everyone.
Good luck!
Found it. find and install Android ID changer. It allowed me to do what I needed.
That's what I needed to change. Somehow someone else had to have the same as mine, hard to believe but that had to be the case. Not sure if its the same thing swype is looking at though
Is it me or does the DeviceID of a Viewsonic G always come back as the same thing on every device?
I'm running TNT Lite. Running certain market apps immediately lets me take over an existing account owned by someone else, and other apps tell me my deviceID is already registered and give me the username / email address of the person who registered it.
First, it's a bad idea for an app to identify the user solely on the DeviceID. Second, it's a bad idea (and probably against the Android specifications) for all devices to report the same DeviceID, I would assume.
I've also written an app that tracks mileage for tax purposes. I developed a web based license solution that allows a user to either purchase the "pro" version through the Google Market, or I can also "gift" it to people, identified by their gmail account.
When I gift it to someone, it allows them to register up to three devices associated with their gmail account and it sends me an encrypted one-way hash of the DeviceID. I've seen a couple of the same DeviceID's associated with users that my own gTab reports.
This also means if anyone tries to set up an app that does any sort of encryption key based on the deviceID that it would be easy to break.
So, long story short, is this a problem with the core Viewsonic build, or is this an effect of TNT Lite? Or are all DeviceID's the same unless you have a cell radio?
VEGAn 5.1.1 has the same problem... found that out the other night while trying to get Line2 going.
If memory serves correctly there's a hack involving the Android Emulator that I'm adding to my list of todos.
Well I found a post here by Chief Beefalo describing how to do it, but his post is wrong when it comes to the viewsonic.
It's stored in the database at:
/data/data/com.android.providers.settings/databases/settings.db
In the "secure" table is a row with device_id. Just update that from sqlite should do the trick. It's a 16 digit hexadecimal number.
Of course then you still need to generate a random number that doesn't still conflict with anyone else...
Now the security expert in me starts to think about how bad it would be to write an app that would roll through a ton of deviceid's and log into Pocket Empires (which only locks it down by the deviceid, no password) and trash people's accounts.
I believe you found the android_id ... check out this write up:
http://augendev.wikispaces.com/Market+Fix
start at step 18
And I can confirm this works. You can use a tool such as Android ID Changer (on the market) to update your id. Once that is done you're now free of all the other custom rom holders.
Line2 is now working great for me!
Here's another link to the same (basic) instructions with a better download link if you have problems with the one above:
http://www.smartqmid.com/wiki/index.php?title=Getting_Android_Market_to_work_with_2.1_v1
Can't I just modify the Android ID with a random 16 hex digit number? It might be a duplicate with 1 device out there, but that would be better than to be a duplicate with every ROM of the same kind?
The emulator solution takes all of maybe 15 minutes. You could also look into stealing 15 of the 32 bytes consumed by a guid. I'd like to find the code that supposedly regenerates the android id and host it on a web page. Curious to learn what its variability is.
Sent from my Tegra 2 gTab using Tapatalk
This is also what we used to do over on the Pandigital Novel Slatedroid forum. It was called the "ugly" Market hack. Maybe it should have been called the "secure" Market hack.
When I originally got my GTablet, I couldn't figure out how to port the ugly hack over, and eventually we found the other Market hack that we currently use. Also, interesting enough, I added the xbin folder into TNT Lite originally to get sqlite because of early attempts to get that hack working.
OK. So I tried the emulator path and the problem I have is that I ended up with a 18 digit Android ID instead of the 16. The Android ID application will not let me change the ID to an 18 digit number, only a 16 digit one. Any ideas?
I dropped the first two digits ... go figure
Btw I'm finding the same Id on every rom ... it is not limited to any one distribution. The only app this has visibily effected for me is line2. Seems fewer and fewer apps rely on this value... atleast on its own. Problem for us is some bring in the imei code and all the gtab is going to do is return zeroes there.
Sent from my Tegra 2 gTab using Tapatalk
Synman said:
I dropped the first two digits ... go figure
Btw I'm finding the same Id on every rom ... it is not limited to any one distribution. The only app this has visibily effected for me is line2. Seems fewer and fewer apps rely on this value... atleast on its own. Problem for us is some bring in the imei code and all the gtab is going to do is return zeroes there.
Sent from my Tegra 2 gTab using Tapatalk
Click to expand...
Click to collapse
So you just dropped the first two digits and it worked? Let me try that!
Thank you!
BTW, I am running Vegan 5.1.1 So this is not a TNTLite only problem. I am guessing that any ROM will have this problem.
Agreed. I've seen the same id on vegan 5.1 and chalkilin.
Sent from my Tegra 2 gTab using Tapatalk
A suggestion:
any coder, or anyone who can modify the "SettingsProvider.apk" can change the creation to something else.
On FolioMod and Elocity i changed it to be based on the "ro.firstboot" value, so any new installs will always be different, and yes it might conflict in any firstboot values match by the second or a minute in other parts of the world but chances are small.
its normally generating it from the ro.serialno value..