[Miscellaneous Android Development] Almighty2:
I never said it wasn't the stock ROM but you were calling it Google Play which meant it had to be 2012, the Kindle Fire existed way before then and people hacked it almost as soon as it came out. Google Play Services was not a requirement for certain Google apps until earlier 2013 when it will take you back to Google Play to install it.

This link already tells you what needs to be done to get Google Play Store on the Kindle Fire HD which is just 3 files, Google Market, Google Services Framework, and Google Play Store although if you read the comments, newer versions of the stock rom already have Google Services Framework and all the person needed was the Google Play Store apk, not even Market is needed.

http://reviews.cnet.co.uk/ipad-and-...le-play-store-on-the-kindle-fire-hd-50010454/

BlueStacks 0.7 and my HP Zeen are such devices but Google Play Services won't install on them because of the shared user id problem. BlueStacks 0.8 doesn't have this problem as there were trouble tickets filed on that issue.

They are doing some type of check when you connect to it. There might be thousands or even millions of devices but that doesn't mean they can't just all base it on the same platform and then when authenticating with Google Play, it will make it think it's that device. And they do have a list except one is a public list and one is a database which is kept on their servers:

https://support.google.com/googleplay/answer/1397129?hl=en

and this is the device list:

https://support.google.com/googleplay/answer/1727131?topic=1100168

See, there is where your problem is. You keep talking about Google Play Store looking at the dpi which is in build.prop, it is not in Google Play Services, GPS is more for apps after you install it as you can install Maps or Youtube for example, but the newer versions that came out about 1/2 year ago will tell you that it requires Google Play Services after you had installed it. The dpi part is also in Google Services Framework which is not the same as Google Play Services which I think is what you are getting mixed up as Google Services Framework is required for Google App and Google Play, Google Play Services is required more for the apps when you try to run it as Google Play works fine without Google Play Services. As you can even see here, with CM, there are gapps depending on the dpi of your device and the only file that is different is the GoogleServiceFramework.

http://wiki.cyanogenmod.org/w/Gapps

Since you keep talking about dpi, why dont you try setting the dpi to the ones you mentioned and see if these apps ever shows up on bluestacks or your Kindle Fire or any device of your choice that is not a phone:

friend trusted, lyft, sidecar, shopkick, uber

And while on the subject, here is a post that shows what changing the fingerprint does on a Kindle Fire...

http://xdaforums.com/showthread.php?t=1423184

so the dpi might show you more apps but it's the fingerprint that will show you the protected apps as well as give you full market access. the dpi might be more for showing you apps that has higher dpi requirements but it won't show you the protected apps which are two different things altogether. Not to mention that unless you are in the US, what you see is never 100% of all apps available anyways. The fingerprint tells it what version of Android you are using and what hardware you have.

This explains it better:

http://androidforums.com/spica-all-...ected-app-market-fix-tutorial-build-prop.html

and this explains exactly what the fingerprint does:

http://chall32.blogspot.com/2010/06/android-market-fingerprints-demystified.html

which could mean that first you have to get the fingerprint which is how many maximum apps it gives the device access to and then the dpi might be based on that app list, it will include only those apps that meet that dpi requirement as a secondary filter since remember things can be filtered by multiple levels.

I never said a backwards facing camera was a requirement, just a camera was and in your case, no matter which device you have as they all have cameras, I'm sure all of them are more popular than the HP Zeen which was the point you keep missing as you don't have a non-camera device to test out the theory and BlueStacks emulates devices which has cameras. The HP Zeen does not even have a stock ROM so if you brick it, there is no recovery method at all as the closest thing was someone getting ahold of some files on their update server which installs just the base OS and then it requires a OTA before one will have all the functions again as it's not a standard Android tablet but rather, it has stuff that controls the printer such as scanning, faxing and printing and basically if HP takes the files offline, you will have a useless brick which can't be said about other devices as there is always a stock ROM you can just reflash.

Google Play Store doesn't require anything more than copying just like the other stuff in Gapps and as long as you can get the google account part working, the Google Play Store will work. Google Play Services is the one that will either install or it won't.

The defaults as the GT-I9100 is because of the /data/.bluestacks.prop file which exists only on BlueStack. But what's strange is some people said their default device changes everytime they uninstall and then reinstall BlueStacks which I have never done since all I ever do is upgrade the existing install and even for rooting, all I do is replace the initrd.img and the Root.fs file. What I was trying to say was why did BlueStacks choose the GT-I1900 as the default device unless that's the device they are using as a reference. So there is always a chance BS selects a different device randomly when you install from scratch, meaning there is no existing install when you install it. As it seems it's always some Samsung device with different model numbers.

The thing may be it's BS that isn't fully open as rooted compared to other devices as you can try manually copying the files to the various location which really only requires the Superuser management program's apk and the su binary but for whatever reason, it doesn't work when you manually do it but it works fine when you put the file into the Root.fs image.

I never said DPI wasn't important but it will only get you so far as the fingerprint is what gives the identity of what your device is capable of or not.

Using your link, read it carefully: http://repo.xposed.info/module/de.robv.android.xposed.mods.playstorefix

Where does it say Google Play Services is involved in the dpi portion? Read my previous post and I said you are configuring Google Play Services with Google Services Framework, the later which is the one that is dpi dependent with versions before Android 3.0. The other thing is unless you have experienced a device where it doesn't show any apps at all and then having to change the fingerprint before it works, you don't have that experience because what you're talking about is things are already working but you're just changing the dpi just to get access to apps requiring a certain dpi because of the developers requirement. This is different when even basic things don't show up in Google Play and when I mean basic, I mean things like Gmail for example.

I'm not talking about the new SuperSU but rather the new CWM Superuser that's on Google Play as a few others can't get SuperSU to work and so far, no one has figured out why because you are using 32bit Windows XP and I'm using 64bit Windows 7 so we can rule out it's due to it being 64 bit as the reason it doesn't work although you have to wonder how BlueStacks is able to work on both 64bit and 32bit while Portable Ubuntu doesn't.

I really don't have time to even read the forums since I'm still trying to go through the last 4 years of emails which is over 160,000 and am only able to go through about 1,000 emails daily and ofcourse every time when you reply, I always get 2 emails because one is the notification and the 2nd one is saying I've been quoted so it's time consuming having to come back to read and then respond and also finding the links. So the dpi thing is harder to test because there isn't any apps that aren't showing up for me for apps that require Android 4.2+ but fingerprinting in build.prop is one way how people got full access to market and things can always change internally. As can be seen here, Market Helper which emulates another devices fingerprint so it will see more apps in the market has the Kindle Fire HD as one of the devices you can emulate so now you know why the Kindle Fire HD is a supported device as far as Google Play Store goes as it's Amazon who doesn't want to give you access to Google Play but Google knows that device meets the requirements since both the Nook and Kindle are popular devices:

http://www.androidpolice.com/2013/0...ted-user-should-know-about-part-7-apps-50-57/

Maybe you can post the process of how you got the last SuperSU working from within BS itself. My BlueStacks always has /system mounted read-only though which is how it is on other Android devices so not even sure how you were able to boot with /system on rw because even when I run root explorer, it will ask if I want to mount /system as r/w when I try to change something in /system. But if what you saying is correct, wouldn't installing CWM's Superuser also run into the same problem as I can go from the rooted SuperSU to CWM's Superuser without problems except the su binary in the newer version's has some bug in it so that's a CWM Superuser issue and not a BlueStacks issue. It's not too hard to test the su binary thing though since all you have to do is install CWM's Superuser with the apk I've attached in a earlier post which is the same version you had in the earlier BS 0.8 and then open the apk and let it install the su binary. After that, run the SuperSU 1.80 which is still installed and see if the su binary installs and if it fails, just replace the Root.fs again. I'll update this post in 5-10 minutes to see if I can get the SuperSU 1.80 su binary to install after I get CWM Superuser 1.0.2.1 working, this is the last version of CWM that has a working su binary, notice I said working su binary because the newer versions installs but as reported in Google Play Store, the apk doesn't prompt and running su in the shell will get a permission denied after some time, probably timed out because of the apk.

Just finished downloading the new package with the 1.80 SuperSU you provided. I'm installing over the previous BlueStacks running SuperSU v1.65 which you provided and then just doing the following on Windows 7 x64 Ultimate:

1) Run "%programfiles(x86)%\BlueStacks\HD-Quit.exe"

2) Replace the existing initrd.img and Root.fs files by copying over the existing one in C:\ProgramData\BlueStacks\Android with the ones from the downloaded archive which have the date/timestamps of November 29, 2013 for both while the timestamp is 7:12PM for initrd.img and 8:14pm for Root.fs, atleast for Pacific Standard Time PST/GMT-800.

3) Started BlueStacks and first thing I did was launch Root Explorer, /system is mounted as read-only but you also fixed the problem where a long press in Root Explorer shows the menu instead of it going back to whatever launcher with the previous SuperSU 1.65 archive. Actually, that may be because it's using the Root Explorer included in Root.fs instead of the one I had installed which I installed during BS 0.7 as there are two versions of Root Explorer 3.1, one is for 3.0+ and one is for verisons 2.1-2.3.4, the later is what I had installed in /data/app which is weird as the system only registers the one in /system/app which is 2.14.2 instead of the 3.1, probably because Android is smart enough to pick the apk based on the API as the 3.1 is for 2.1-2.3.4, see attached and you will know what I mean. Looks like the Root Explorer included is pretty old as there is no change of owner/group as that was something I suggested to the author of Root Explorer by email on March 6, 2011:

"Greetings:

I have some suggestions of features for root explorer to add:

1) There should be a option to allow changing the owner/group of a file/directory

2) For permissions, there should be a option to do the S or s flag which is needed for some files/directories

3) There should be a option of what directory to extract to and the option to create the directory if it doesn't exist.

Thanks!

in which the reply was:

Hello <name>,

Thanks very much for the suggestions. I’ll add these to the to-do list and hopefully at least numbers 1 and 2 will be implemented quite soon.

Cheers,

Colin"

In any case, I replaced the Root Explorer apk in /data/app and now it's seeing both the one in /system/app and /data/app and using the one in /data/app.

4) Running SuperSU v1.80 from the launcher works fine, apps can prompt it for root access and su works in terminal

5) Running CWM's Superuser 1.0.2.1 and letting it install the su binary which also works for prompting for root access and su works in terminal.

At this point, the SuperSU icon is missing from the launcher but the apk is still in /system/app so back to Google Play to install SuperSU v1.80.

After installation, opening SuperSU v1.80 prompts updating the su binary so I choose the regular method of install and in less than 1 second flat, it says installation failed for the su binary.

Replacing the Root.fs as the initrd.img still has the original time/datestamps. This time it uses the Root Explorer 3.1 I have installed but the same problem exists, long press sends it back to whatever launcher I use instead of displaying the menu. There is a work around as one can just select the file and then click on the menu button. Seems like it's a bug with Root Explorer v3.1 which works correctly with my other devices, both Android 2.x and 3.0+ as 3.1.4 works correctly in BlueStacks and this is the change log:

v3.1.2

• New themes (available in preferences). Light, light with dark action bar and home wallpaper (including live wallpaper).

v3.1.3

• Updated to use latest Android SDK (4.4) and Google Drive SDK.

• General performance and stability improvements.

• Fixed bugs reported since last release.

v3.1.4

• A couple more bug fixes. Thanks for your help in tracking these down.