Jagex Q&A response to botting concerns on mobile:
https://www.reddit.com/r/runescape/c...anscript_1907/
Generally I don't take much Jagex says seriously anyway.
Jagex Q&A response to botting concerns on mobile:
https://www.reddit.com/r/runescape/c...anscript_1907/
Generally I don't take much Jagex says seriously anyway.
Last edited by Clarity; 07-19-2017 at 09:12 PM.
Scripts: ClarityNex | ClaritySlayer | ClarityElfThief | ClarityBurialArmour | ClarityMudRunes | ClarityWells | ClarityProTables | ClarityArmadyl | ClarityHarps
ClarityDominonTower | ClarityAltar | ClarityCitadel | ClarityBarrows | ClarityEsswraith | ChampionScrollCamperTools & Extensions: OpenGL ID Highlight Tool | SRL-6 Messaging System | SRL Companion | Item DTM Generator | BBCode Converter
I agree AND disagree. Yes I agree it would be a false positive. You have youtube to check out what it's like. Nice reviews and stuff. I'm sure Jagex will post a video of the entire experience and how it works and how they got to that point.
Most people have a smart phone. The only people that really know what simulators are.. are developers. As you yourself are a coder, I'd bet you have a device. No smart phone? What about tablet? With Android phones as low as $60 CAD, I can't imagine anyone without a smart phone or tablet AND playing OSRS AND wants to try it on a simulator AND owns a computer powerful enough to run the iOS and Android simulators. The chances of all of those being true, is very slim. They are paying membership, they own a computer, they have a router & modem and internet.. but yet they do not own a phone and they're tech savvy enough to run a simulator..
1. If you're using a simulator, you most likely have some experience developing apps, games, or software.
2. If you are a dev or have experience developing software or even just a bit tech savvy, you most surely have a smart phone.
3. If the above is true and you do have a device, there's no reason to use the simulator other than for botting.
All I'm saying, is that as an app developer, they'd be the first to get banned regardless. There is already a stand-alone executable and a browser version and they're still going to pull the "I wanted to test the mobile version on my computer capable of running the simulator"? Sure the first time you let it go or ban them and they can appeal. The second time they're doing it, I'd ban them regardless of whether they were botting or not. After all, they should technically be using the browser or standalone to play on a desktop. That's what it was made for. I'd of course add other measures to make sure they're not actually just testing it, but I'd put them on a list the first time they even "tested" on a simulator.
That's very very unlikely. I haven't ran bluestacks on a decent computer but Android simulator bundled with Android studio is absolutely awful! Very simple iOS app: http://i.imgur.com/yRfIwAi.png already taking up 300mb+ of memory for the app alone (simulator memory & cpu usage not included -- no JVM like due to being an iOS app too). Now imagine a game like OSRS. The problem? In the simulators, they know there are more resources and memory available so it can allocate as much as it wants and needs.. however, on an actual device it uses WAY less!! Why? Because sandboxed apps don't have that much memory available and other apps need memory and resources too. Simulator has unlimited so it of course stores as much as it can in memory: https://stackoverflow.com/questions/...tor-and-device However, none of this is a definitive answer as to whether it will indeed run better than the desktop version.. but my money is on the desktop version for both usability, performance, and stability.Another potential [legitimate] reason off the top of my head to check out rs mobile via an emulator might be to see if it's more efficient to run rs3 in a mobile emulator than running the desktop client. If it's less resource intensive (the desktop nxt client tends to utilize 100% of available gpu resources) and/or more efficient usage of a smaller window, then perhaps either of those reasons could make for a better experience with certain activities (e.g. skilling when also focusing on other things). Thus imo could be something that people might wish to check out.
Anyway, I'm not discouraging trying to bot on mobile. After all, we're all curious and have to try this out. I'll just be doing it on my actual device on a dummy account. If simulator is feasible to bot on, sure I'll try it too but I won't ever be using my main account on any simulator.
Last edited by Brandon; 07-20-2017 at 01:04 AM.
I am Ggzz..
Hackintosher
I definitely agree with the sentiment that the vast majority of users on emulators/simulators in the longterm would be trying to rule break and thus they should make an explicit rule disallowing the use of emulators and then instaban for doing so. If however they're going to remain going with the whole "we know what we're doing, trust us, cant give up secret intel" then, there's imo a very definite risk of false positives occuring (some potential legitimate reasons given earlier on why it might be worth atleast checking out), if they were to be doing the whole instabans based on emulator detection without a rule against it. I personally cant see them doing instabans for it without a rule against it, however, using it as a part of the botwatch (e.g. if you're on an emulator then there's a lower threshold in their system necessary for you to be banned) I can definitely see happening.
As for me owning a smartphone, yeah even though I dont use a smartphone as my main phone, I do have an older android smartphone that I keep around as a backup. I am the noobiest of noobs when it comes to smartphones, just a small handful of total hours spent using them in any capacity. Also thinking a bit about myself, I really am quite an outlier, I actually used an emulator before ever using a regular smartphone of my own. For the app whatsapp, a while back, in order to get in contact with some people. I used bluestacks and passed it my regular mobile # in order to have a psuedo-smartphone that could send and receive messages in their network.
Anyways, I'm personally interested in getting some experience with doing a bit of macroing on a mobile app, regardless of how effective it would be e.g. even if it ends up being instabans every time, even on actual smartphones. Looks to me like a good learning experience overall and this is a decent reason to mess around with it in my spare time, perhaps improving my abysmal java knowledge along the way. Ideally working together with some other people on it. Either way, worst case scenario: learn some stuff and lose some disposable accounts ¯\_(?)_/¯
Hmm, looks like vBulletin doesnt like the shrugs emoji.
Last edited by acow; 07-20-2017 at 02:24 AM.
Agree, pretty interested to start playing around with botting on emulators, regardless of whether it's an instaban. Seems like a nice pathway into understanding some aspects of app development which I continue to make stabs at.
If like @the bank; says, they solely base bans on heuristics, then they don't have to do much regarding mobile. Will be interested to see if we can circumvent this.
Scripts: ClarityNex | ClaritySlayer | ClarityElfThief | ClarityBurialArmour | ClarityMudRunes | ClarityWells | ClarityProTables | ClarityArmadyl | ClarityHarps
ClarityDominonTower | ClarityAltar | ClarityCitadel | ClarityBarrows | ClarityEsswraith | ChampionScrollCamperTools & Extensions: OpenGL ID Highlight Tool | SRL-6 Messaging System | SRL Companion | Item DTM Generator | BBCode Converter
Simulators, sure, but plenty of people use emulators. There are a ton of very popular addictive games that incentivize you to be logged in 24/7. Games like: Deep Town, Tap Titans 2, Nonstop Knight, tons of CoC clones that don't allow you to be attacked while online, and many more.
It isn't uncommon for people to play these on emulators to gain an advantage (and save their phone's battery).
Also, I think the Android SDK comes with an emulator, not a simulator, so it makes sense that it wouldn't run as well as a decent phone. Apple's is a simulator.
¯\_(?)_/¯ Buuut I could be totally wrong ¯\_(?)_/¯
e: Damn, those characters were fine in the preview. oh well ?????
The ADK provides an emulator, not a simulator. The emulator is almost a standard implementation and in case of discrepancy in behavior between emulator and real device the real device is usually at fault.
Further there are apparently some ways that might detect an emulator, but at least one of the fields you can check are labelled with "Do not attempt to parse this value" in the documentation. Further, some ROMs seem to provide values that some checks would report belonging to the emulator. It seems like there is a way to detect running in an emulator for now, but you can easily change any of those values. The lack of dedicated API seems to imply that Google does not want you to be able to detect if you are running on the emulator. The emulator is presented as a first-class device in the Android ecosystem.
Based on my reading it is relatively common for Android developers to be entirely deviceless. If they do have a device, they probably only test on it and the emulator.
The Android emulator can run the play store and some simulator images come with it preinstalled. If you're compiling it for the app store you are compiling it for the emulator. If you want to add terms to the use of your software that prevent it from being used on an emulator (probably because you are conflating non-emulator installations and unique installations) then you are free to do that. However, you will likely not be able to enforce it.
Despite the paragraphs you've dedicated to this conclusion it's still based on fallacious reasoning. Jagex could implement this policy, but they will end up banning real players.
The Android emulator uses more memory because it is allowed to. If you set the options for QEMU yourself you will use less memory.
The iOS simulator is nearly a joke, most good developers test on device because the simulator doesn't accurately reproduce real devices.
Last edited by R0b0t1; 07-20-2017 at 02:42 PM.
The jealous temper of mankind, ever more disposed to censure than
to praise the work of others, has constantly made the pursuit of new
methods and systems no less perilous than the search after unknown
lands and seas.
TLDR: I am still going to bot on it as I stated before. I was simply addressing that you guys actually thought the simulator & emulator was undetectable which is 100% not the case.
As for your little iOS bashing (* I develop for both platforms [no bias here -- Android is easier to dev for, but the emulator is ass] *)..
The iOS simulator destroys the Android emulator in performance and stability. Even with AVD's GPU host turned on and Intel Virtualization turned on, it's still trash https://stackoverflow.com/questions/...hone-simulator. I don't know why you say it's a joke. When you compile an iOS app for the simulator, 99% of the time it is exactly how it is on the device. Only difference is the simulator performs better. For Android, the emulator performs terrible compared to an actual device but is just as stabled. I call BS on android developers commonly testing without a device.
Furthermore, "it uses more memory because it is allowed to".. So does the iOS simulator.. I don't understand you point. At least the iOS one doesn't use Gigabytes of memory, and still outperforms the Android emulator. No real development company tests on the computer. A real device is necessary. QA (Quality Assurance Testers) isn't going to load up your code and test it. If you're a single Android developer, you own a device OR use the emulator until you can afford a device. But at companies, that never happens. You are provided tons of devices to code on, and either a really amazing computer or a crappy one.
You say my findings are false, but link to an article which states you CAN detect the emulator.
In case of discrepancy, the device is at fault? Do you say the same thing to the users when they downvote your app to oblivion?
Everything else is correct. I certainly agree with the part where you can install stuff from the playstore which you cannot do on iOS. However, when you compile an iOS app, it too is also compiled for the appstore for a real device just like Android so you lost me there. When it is submitted, Apple recompiles it and strips it and optimizes it for each device themselves as well.. If it crashes during review, they reject it. If it doesn't work during review, they reject it.
But I'm not here to argue iOS vs. Android.
--
All in all, I'd use a library that is dedicated to doing just that (detecting): https://github.com/framgia/android-e...rDetector.java. You can detect the simulator and emulator and I'd ban you for it if it were my app. There is a desktop version available which you seemed to skip right over, so I can only assume you are either curious (first time offence.. any detection thereafter or after monitoring you) or a botter. Yes I have already stated and agreed that there would be false positives but that's a sacrifice I'd make as an app developer. It's the same sacrifice Banks make when they detect Jailbroken device and do NOT proceed to get past the login screen. It's a sacrifice for security and protection of your product. On a computer you have WAY more freedom and it's WAY easier to reverse engineer and break your security or circumvent it. On a device it is much harder. It rules out the noobs from the real hackers and makes things harder for them as well.. It's justified.
I'm not going to bother answering that. If it's in the TOS of course you can enforce it so long as you actually code the app the person is using.. It is YOUR PRODUCT. If you aren't going to protect it, who will?? I'm not sure why you guys think Jagex "wouldn't do".. Everyone said the same thing before bot nuke and they certainly delivered. Simba survived, but not many others. It took months before things became stable again.However, you will likely not be able to enforce it.
I am only saying things that CAN happen. You are saying that it won't. I am going to now ask you to prove that. As the saying goes.. they can, but they don't. If one day Jagex decides to stop that.. you'd be the first one out the door; I'm sure of it.
Last edited by Brandon; 07-21-2017 at 12:30 AM.
I am Ggzz..
Hackintosher
Maybe with no modifications, but the API you could theoretically use to detect emulation is limited. You can fake all of the returned values.
What findings? I didn't say anything you found was false, I said your interpretation of what is possible was wrong. People use the Android emulator for all sorts of things, even if only for the novelty of it. There is no dedicated API to detect being run in the emulator and you can easily fake the values used to check for emulation.
What I said was that if there is a difference in behavior between the emulator and a real device, the real device usually has a bug. That doesn't mean the phone manufacturer is going to fix it.
You're seriously overestimating how capable you (or that programmer) are. All of the tests in that file are heuristics, and they can all be faked.
But you have to enforce it in some way. If you can't actually tell if people are violating your terms or not, you can't do anything about possible violations.
No, I said that if Jagex bans people for using the android emulator they're invariably going to ban a real person at some point. If I pay them money and want to play the game using the Android emulator I see no reason why they should have a problem with that. Paying customers have been banned for things less extraordinary, and I suspect this might become a problem for Jagex in the future.
The jealous temper of mankind, ever more disposed to censure than
to praise the work of others, has constantly made the pursuit of new
methods and systems no less perilous than the search after unknown
lands and seas.
What? The emulator emulates the real device. How can the real device be wrong then? If there's a bug, it's the emulator's fault because the device is what is being emulated. Otherwise it is a bug in the OS and will be fixed in the next OS release.
You actually believe you can fake all the things in that file which you call heuristics? Please feel free to try it. Some of those are mapped files, sockets, pipes, hardware.. Yeah go on then. I'm not overestimating anything. I simply think you have no idea what you're talking about. You're going to have a lot of work to do to circumvent every single way of detecting the emulator (even other ways that aren't listed in that one file).You're seriously overestimating how capable you (or that programmer) are. All of the tests in that file are heuristics, and they can all be faked.
But you have to enforce it in some way. If you can't actually tell if people are violating your terms or not, you can't do anything about possible violations.
I don't think you're reading. Again: I already know there will be false positives.No, I said that if Jagex bans people for using the android emulator they're invariably going to ban a real person at some point.
Well I pay bank fees.. I see no reason I shouldn't jailbreak my own device, which I also bought with my own money. I pay for this game, but developed my own 3rd party client (also applies to bluestacks - an android emulator), I should be able to use it -- Your logic is sound. I shouldn't get banned for using RSBot but playing legit in it right? Because after all, I never ran a script and I didn't bot on a 3rd party botting client. I played legit, trust me and don't ban me.If I pay them money and want to play the game using the Android emulator I see no reason why they should have a problem with that.
Again: You do realize there is a desktop application right? They can simply say that you cannot use emulators in the TOS, then what?
I am Ggzz..
Hackintosher
They will most likely introduce a new interface just for mobiles and you probably do need custom rooted devices to run bots but I don't know if that'll be out any time soon.
Yes they do contradict. It's easy on iOS: https://stackoverflow.com/questions/...rtificate-info and you can overwrite it by decompiling it and removing it or adding swizzling the method that is doing it, but it's a lot of work. I'm not sure for Android.
Last edited by Brandon; 07-23-2017 at 06:52 PM.
I am Ggzz..
Hackintosher
Because the emulator is associated with the SDK and is easier to control than a myriad of unique devices. If there are phones that behave differently than one another, which one is right? They can't both be right, Android is supposed to function the same on each device (barring things like TouchWiz).
I've covered all of this in my other posts:
- You can fake those things, and if they have a filesystem presence it's very easy. Create a chroot and provide whatever name you want. If there is money involved someone will do it eventually.
- If you know there will be false positives then we agree.
- This seems to be Jagex's stance with SMART, though I suspect you shouldn't go telling moderators you are playing while using a client originally intended for botting.
- That is entirely their prerogative, but I doubt they will have much luck enforcing it. What if I run it on a Hardkernel device flashed with an Android system image? Will it look enough like a phone to pass? Is that against the TOS?
The jealous temper of mankind, ever more disposed to censure than
to praise the work of others, has constantly made the pursuit of new
methods and systems no less perilous than the search after unknown
lands and seas.
Runescape mobile is a terrible idea, the amount of restrictions you'll have you cannot pk , you cannot pvm , you can only bank stand and skill at a terrible exp rate not sure why they're wasting resources and money on this when they can do more updates for Oldschool/PvP Content to bring players
This is where I disagree. Windows for example runs on many different devices. However, on different HARDWARE, it behaves oddly at times. That doesn't mean it's the hardware's fault. It can very well be an OS issue. Windows on hardware may behave differently than windows in VMWare or an emulated environment. That doesn't necessarily mean its the device it's running on fault. It could also be the emulator having bugs.
It can actually be BOTH. Why? Android is open source and different manufacturers may modify things to work differently on different devices. Because we know this as developers, we can't depend on the emulator. Emulators TRY to emulate the hardware as close as possible. It's never going to beat real hardware.
Apps can behave differently on different devices. Doesn't mean the emulator is wrong and it certainly doesn't mean the hardware is wrong. It depends on whether or not it's actually a bug (which can exist for either the emulator or the device being emulated). I'd rather trust the hardware that I have in my hand that any emulator. User's aren't going to care about whether or not you tested on the emulator. They are simply going to say: "I have this device and your app sucks.. doesn't work". "Doesn't Work" is one of the worst things a user will tell you (no info at all).. but your emulator won't.
I've covered all of this in my other posts:
- You can fake those things, and if they have a filesystem presence it's very easy. Create a chroot and provide whatever name you want. If there is money involved someone will do it eventually.
- If you know there will be false positives then we agree.
- This seems to be Jagex's stance with SMART, though I suspect you shouldn't go telling moderators you are playing while using a client originally intended for botting.
- That is entirely their prerogative, but I doubt they will have much luck enforcing it. What if I run it on a Hardkernel device flashed with an Android system image? Will it look enough like a phone to pass? Is that against the TOS?
- Sure I can see system files being modified and replaced or faked. I can't see pipes and other things being faked.. especially when the emulator "depends" on it. Yes, if there is money involved someone will take the time to do it.
- Yes. Of course.
- They just have more pressing matters to attend to imo. Remember when you'd get banned just for logging into powerbot? So much so that there is almost a 400+ page thread about it on pb. "They can, but they don't".
- Right now, there's nothing in the TOS about it. I was just saying they "can" add it. Enforcing it is another matter. All it takes is one update (remember how Pokemon Go banned all those players in a single update - Cat & Mouse game). Maybe it will look more like a phone and pass yeah. But you'd do all that just to run it? or to bot it?
Last edited by Brandon; 07-25-2017 at 01:15 PM.
I am Ggzz..
Hackintosher
You're really arguing against the point you made in the first paragraph in the second paragraph.
Windows runs on lots of different hardware, and ostensibly it should offer the same user experience on all of that hardware except for when the capabilities of that hardware make the OS more or less functional. Every other case where the hardware causes differences in functionality is pretty much the definition of a bug. Is this the OS's fault or the hardware's fault? Well, it's the job of the OS to run on available hardware, and in my personal experience it seems to be more common to have to patch things like QEMU to implement technically undefined behavior than it is to have Microsoft go back and add support for a new platform.
When you say it's "both" - I never discounted this, but in either case it is still the manufacturer's fault. They modified the hardware the OS is running on and the OS. If it does not behave the same as other devices then something is wrong with their implementation. It might be prudent to have some devices to test, but if everyone is doing this then you're letting manufacturers push off the cost of their poor engineering onto you.
It's an emulator, emulating real hardware. The emulator is real hardware. Just because it has different behavior in some cases than real hardware doesn't mean it's buggy; on the contrary, it probably means the "real" hardware is the one with bugs!
This is like trying to argue that the JVM should behave differently on different machines. It shouldn't, because that's part of its design.
If the emulator isn't at least intended to be representative of all Android devices as a whole, then why does it exist? If what you are assuming is true and it can't be trusted and was never intended to be trusted as a representative example, then there is literally no reason for it to have been made.
If you obtain different behavior by detecting hardware capabilities (like a better GPU) then that is completely normal. However you can't actually detect most platform differences directly, like if you are running on X phone or Y phone, because it shouldn't matter. Relying on differences in implementation behavior is a bad design choice when programming for Android because the OS was designed specifically to abstract over all of those differences and there shouldn't be any implementation-specific behavior. I know users are simply going to see it not working, but when you get bug reports you can explain the situation to them and they will likely understand and come back when you publish a fix - in the best case, they will push their device manufacturer to implement a fix.
The jealous temper of mankind, ever more disposed to censure than
to praise the work of others, has constantly made the pursuit of new
methods and systems no less perilous than the search after unknown
lands and seas.
What do you think "Machine dependent, implementation defined or platform specific means"???
First: ProcessBuilder runs different on different machines and OS. The JVM TRIES to behave the same on all machines/platforms.. it can't. Eventually it has to hit the hardware. Ever hear the phrase: "There's no such thing as cross-platform, just a lot of hard working people writing lots of code to make it seem transparent"? I like this article: https://news.ycombinator.com/item?id=12376715
As for emulator.. Here is the best example of an emulator completely screwing up.. Games! Android supports OpenGLES which leaves a LOT of things hardware specific and implementation/vendor defined by the specification itself. OpenGL relies on hardware, memory, specific instructions, GPU, etc.. Your emulator will emulate the best GPU it can, and render using the HOST machine's GPU. Your emulator will emulate a specific CPU and specific set of hardware (GENERIC).
Then you run your game on an actual device and get F***ed.. Your texture renders differently.. your shader doesn't work.. You think the user will then say: "Oh I'm sorry bro, I'll contact the manufacturer.. must be my device". LOL.. It's not his/her device. It's your fault for trusting the emulator and blaming their device because it worked on your COMPUTER emulating generic hardware. How you can even blame the hardware is beyond me.
Real life example that is happening to me right now. In Unity3D, DEFERRED rendering (Camera rendering mode) is used to do real time lighting and reflection via shaders (aka PostProcessing Script). When the HARDWARE doesn't support it, Unity defaults back to FORWARD rendering. Code works on iOS. Code works on Android. Code works in simulator. Code works in Emulator. Code works on OSX. Code works on Windows. Renders beautifully.. NO LIGHTING OR REFLECTIONS TO BE FOUND ON ACTUAL 99% of HARDWARE! Run it on a Samsung device.. reflections and lighting works flawlessly. Run it on a Google Pixel, no cigar. Run it on 7 Android devices (2 other pixels, a few Nexus devices, HTC, etc).. no cigar.. Run it on 9 iPhones (different devices and OS versions -- doesn't even work on iPhone 7 -- not even working with Metal API enabled).. Does NOT work!! Even worse than Android (Black screen on iOS).
The only device to ever get it working was some Samsung Galaxy device. Unity knows this and they detect your hardware via JNI and Android API's. Otherwise you're going to be loading invalid shaders every single time. How else do you think they do that "fall-back to forward rendering" mode?
So now, tell me. Is the device right? Or is the emulator right? I'm 100% sure the device is correct. GLES supports deferred rendering "depending on the hardware". Now go ahead and tell me I can't detect your hardware..
The emulator isn't meant to emulate ALL android devices. It's meant to emulate the most typical environment and GENERIC hardware.. In some cases, it emulates specific hardware like Nexus devices (as closely as it can). However, when it gets it wrong, a patch is released to the emulator and not the device because it is never the device's fault (unless something is physically wrong with the device itself - manufacturer defect). Let me know when you find a company that only tests on the emulator.If the emulator isn't at least intended to be representative of all Android devices as a whole, then why does it exist? If what you are assuming is true and it can't be trusted and was never intended to be trusted as a representative example, then there is literally no reason for it to have been made.
However you can't actually detect most platform differences directly, like if you are running on X phone or Y phone, because it shouldn't matter. Relying on differences in implementation behavior is a bad design choice when programming for Android because the OS was designed specifically to abstract over all of those differences and there shouldn't be any implementation-specific behavior.
Lol.. I'm actually done talking to you about this. Cool guy, but you're frustrating me. It has taken more than 4 posts to explain.. and you just don't get it. I think you have no idea what implementation defined or platform specific or hardware specific is.. You truly believe your hardware can't be detected? What is this: https://stackoverflow.com/questions/...or-device-type
Yes I know SOME can be spoofed.
I personally hope you never release an app to the store. --- As for your other statement, users will likely understand that your (the developer, not you specifically) code sucks, not their device. When users can't get Simba scripts to run, they're not going to blame their computer or themselves. They blame Simba and SMART directly or the script writer (only the rare few users have a "ohhhhh I see.." The wtf it's my fault moment). Apps are even worse. Apps are meant to "just work". You think some user is going to contact the manufacturer and say: "Hey you screwed up, I can't run app made by developer Robot1 for Company XY".. LOL.
There's a difference between: "We don't support this platform" and "Hey, my code doesn't work, it's your device's fault.. it works in my emulator". If it's one device of that kind that isn't working, sure. If it's all users with that device, your code sucks.
Anyway, emulator & hardware can be detected and is harder to spoof than you make it seem. /thread_derailed.. I'm out and I'll wait until Jagex releases the game.
Last edited by Brandon; 07-27-2017 at 02:45 AM.
I am Ggzz..
Hackintosher
I'm not really sure I should quote your post because most of it is irrelevant.
- From an end user's perspective, the JVM behaves the same on all supported operating systems. Of course it has to be implemented differently for each operating system.
- Your digression about GPU capabilities differing wildly between devices is interesting, but I specifically mentioned this being one of the cases where the hardware will differ in one of my posts. These differences are handled by OpenGL, not Android. Both devices are correct as they expose a GPU via Android's interfaces and can run binary code via the JNI.
- How will the emulator get something wrong in a way that makes it more at fault than a real device? The emulator is a real device, albeit one that runs on an x86 processor and that uses a compatibility layer to obtain most of its hardware. As it was implemented from the ground up it will have less hardware-related baggage and can be kept cleaner than most other Android implementations. It will no doubt have bugs, but the interesting cases are those in which the emulator "is running properly" and does something different than a physical device which "is running properly."
- All of those are not intended to be used to identify a device, but yes, if you query enough properties you can usually uniquely identify a device.
- You keep saying it's hard to spoof these things, but I gave an example of how it would be possible to spoof many of the items used for heuristic OS detection that have a filesystem presence. You offer no comment as to why it would be hard to do.
- If the situation is closer to what you said, a private application for a company, then yes I would hope the person who has hired you listens to your advice. If it is publicly I would mention the manufacturer's defect in the notes. You will still probably need to work around the problem but there is no need to accept it as unfixable.
You need to understand you're not explaining anything, you're just repeating yourself. When you add exposition to something you're just making unfounded assumptions about my argument and often times they are things I already mentioned.
The jealous temper of mankind, ever more disposed to censure than
to praise the work of others, has constantly made the pursuit of new
methods and systems no less perilous than the search after unknown
lands and seas.
Thanks for sharing all this info! Great stuff
UI Mockups released:
Scripts: ClarityNex | ClaritySlayer | ClarityElfThief | ClarityBurialArmour | ClarityMudRunes | ClarityWells | ClarityProTables | ClarityArmadyl | ClarityHarps
ClarityDominonTower | ClarityAltar | ClarityCitadel | ClarityBarrows | ClarityEsswraith | ChampionScrollCamperTools & Extensions: OpenGL ID Highlight Tool | SRL-6 Messaging System | SRL Companion | Item DTM Generator | BBCode Converter
There are currently 2 users browsing this thread. (0 members and 2 guests)