I found many references to shared user IDs among two apps and it looks like what I'm looking for.
What I'm concerned about is that there are statements like permissions will be shared between the apps. If one of the apps is a system app, does that mean that the normal app will have system privileges too?
I want one app to be a regular app and one app to be a system one. I don't want the regular app to have any of the system admin privileges.
We are doing this so we can share a Content Provider. Our data is on the edge of being complicated enough for this, but I feel it's justified.
It appears that this is something you can't do. If you set up your system app as shared, you don't get any kind of an error, but Android appears to refuse to acknowledge it.
I took shared back out of my manifest file and it is working fine now.
Live and learn...
Related
Is it possible to get the user behavior on the phone (for example Alpesh has an Android phone and he uses multiple apps, browser YouTube etc). Whatever he is doing on the phone I want to get all those things from behind (which apps he has installed, which app he opens and what he search on the phone, All these data I want to get programmatically so what all can be get in android).
For now I am aware that installed apps list can be get easily but I want to get usage history and what he do all on mobile.
This is not a code solution, but an answer to your question, so you can get start some where.
In my opinion your question title are asking about two things.
(part 1) Getting User Behavior on the Android Phone (part 2)(App History, Browse
History etc)
1- First part Getting User Behavior on the Android Phone:
There is a concept called context awareness. Short described; it is about gathering different information from the phone, like light sensor, motion sensor, sound, location or even user behavior etc. and depending on your app requirement and the gathered information:
You could send these information over cloud data store for statically usage
You could make your phone doing (behavior) different things depending on location, motion or what ever.
etc.
For context awareness it is an open area for pervasive computing research. And it is not just few lines of code to write, it is typically a complete solution depending on requirement. Example I have built a context awareness application to gather noise collected by phones from different locations for research purpose inspired from this framework, but I am pretty sure you can find other frameworks or even build your own, as I did in my case.
The mentioned framework has some examples.
2- The second part is about App History, Browse History etc.:
This is possible, but you still need to build a peace of software (App) to collect all these information (logs) from the phone. Hereafter you can make phone act on different conditions and/or again send it over a RESTful API over cloud service data store, there is no limit for it.
The problem is, there is no thing out of the box for your requirement. Even if you find frameworks you still need to research it and further work on it.
You can find different examples for your requirement, like to collect browser history, you can find SO question here:
Get browser history and search result in android
Or get list of installed application:
How to get a list of installed android applications and pick one to run
My point here is you need to solve small goals at a time and put your knowledge together at the end.
Both 1 and 2 can also be related to each other, depending on your achievement.
Conclusion
Make a goal to your project.
Define the main requirements and tasks of your project.
Research your options (Technology, Cost, Target Audience, What data I can or I should not collect, what is possible to collect, what is the limits, Privacy issues etc.).
Split your project in small assets and try to solve small problems/goals.
Finally you would be able to put the puzzles together and build your final application
but i want to get usage history and what he do all on mobile
This is not possible and shouldn't ever be possible. Each app is sandboxed by Android so apps cannot inspect what other apps are doing. Think about it, you wouldn't want apps to be able to intercept private information such as banking details.
Every app is isolated from the other ones. Unless you develop a system signed app, you will not be able to gather all that data.
What you could do is to develop your own Android Rom where you then develop your data collection the exact way you want. Then you need to distribute your rom, which is another story...
I want to implement unlockable characters that can be purchased and I have a few questions about the best way to implement this in my game.
Currently I manage unlockables by storing them as preferences. However I'm now in the process of making them purchasable.
Is gdx-pay the best way to do this or create a native Android\iOS
implementation?
Once a method of purchasing characters has been implemented and the
user purchases one, what happens when the user uninstals my game?
i.e. should I reverify purchases on startup? This will require an
network connection, if the user doesn't have one it doesn't restore?
Should I be using preferences to store unlocked characters etc or
another method? My reason behind this method was to avoid having
ship a database with it and having to create separate sqLite
implementations for each platform.
Any advice would be much appreciated.
Point 1. Yes, for now if you want to go cross platform then gdx-pay is your choice. Recently they've also added support for IOS 9 which is great. You will be able to deploy on both Android and IOS with minimal change of code.
Point 2. You should always call requestPurchaseRestore in your splashScreen or somewhere on startUp to restore any purchases. This will ensure that even if the user uninstalls the game and installs it on another mobile device they will still have the purchases they've made. Of course, network connection is vital. If you don't have network access and you call requestPurchaseRestore you will get an error. That's why you should have a method to check if the user has access to the internet (wi-fi or mobile enabled) and only then call requestPurchaseRestore. If the user doesn't have internet they won't be able to restore Purchases. I don't see a problem with that. You can put a label somewhere that you need internet to restore purchases.
Point 3. Yes, having a local preferences file is a good idea. This is what I do myself. If an item is purchased you simply store it in the file. You may well use a db too but it's too much hassle for this kind of job.
I am currently trying to find a way to programatically inject items into a mobile browser's cach on Android devices. The browser type doesn't matter, it can be Firefox, Chrome, Android's built in browser, etc.. Is there any documentation or examples of ways to programatically inject objects into the browsers of Android devices?
Not really an answer, just a heads up. Seeing that your question is tagged java, I assume you want to do this from an application, and not from the browser. I'm pretty sure that's impossible, because each Android app is running in it's sandbox. Communication between apps is done through Intents and IPC. In both cases, you are limited by what the target app is offering support for.
You can use proxy, to get this structure :
Client => Your APK => Server
(Like this application).
With your APK you can choose file to send.
Like already mentioned by Corneliu, its impossible for an normal android app to write into the data section of another app.
Although it should work when the phone is rooted. Apps like TitaniumBackup which require root can read and write the data saved by other apps. You can use TianiumBackup to make a backup of the browsers and look in the *.tar.gz file for the internal data structures and the SQLite DB files...
Google Play Developer Program Policies says:
An app downloaded from Google Play may not modify, replace or update
its own APK binary code using any method other than Google Play's
update mechanism.
I want to publish my application to Google Play. And I been planing to load my core SWF file dynamically, so game updates could be done without the need of going to Google Play market. An alternative Java implementation can achieve the same thing by downloading remote jar file.
In both cases I will have the next limitations:
I cannot modify my Manifest file.
I cannot extend the application permissions that I asked
My external code is bounded to application sand box(Just as the rest of my application)
Notice that my external code is not part of the APK files. It will be stored in application folder or in external storage(SD-Card). Its same place where external assets is stored.
Does this violatating Google policy? I am not sure what they meant by "APK binary code".
I am not a lawyer, and I don't play one on TV...
Your best course of action is to look at the reason they included that phrase in the first place. That text now exists in the Google Play policy because Facebook did the very same thing that you are describing in their application (providing an auto-update mechanism outside the Play Store) earlier this year, and Google threatened banning the application until this "feature" was removed (which it was, shortly thereafter).
The spirit of the law in this case is that Google does not want applications updating themselves without the user's consent outside of the Play Store...period. If your application does this, you can bet Google won't care how you are doing it and will likely remove the application when and if the feature is discovered. They won't care how closely executable code in an external SWF file resembles the internal classes of the APK.
Legal language like this is is intentionally vague so companies can apply it in any situation they see fit. Don't think you're being safe by splitting hairs with the terminology.
I am not a lawyer. I see this restriction as limiting only the apk binaries. There are many apps that have dynamic behavior changes, for example Google search where the search results algorithm is determined by dynamic code on the server, or facebook which loads new images texts, layouts and more.
I think that as long as you do not do anything bad for users using the swf changes, you should be ok.
The purpose of this clause, as I understand it, is to prevent apps from loading and using code that was not tested by Google using the normal process that tests apps when published. Google want to ensure that all code is scanned/tested by their bots.
From what I know, you can't get the exact number of users which downloaded your app, unless you're connected to your Google plus account. Is that true? (I haven't yet got a google play (android market) account, my app isn't yet up on the market, so i just wanna make sure i'm saying valid things here.)
Is there any way i could programmatically get the number of downloads, preferably in real time?
From what I've found, there isn't an API for the market which let's me do this. So how can this be accomplished?
I need to take that value and in real time update a graph on my website and blog.
Can anyone come up with a workaround for this? One thing i was thinking of was: to either make a Firefox extension which on my home machine, automatically connects to my Google plus account, takes the required value and updates the page via ftp or something, or instead of Firefox extension i could use PHP locally to do the parsing and whatnot. But i'd need to keep my home machine always on, which i don't really want to.
Any other ideas? I really need that exact value, and i need it to be automated :)
When the user downloads the app, you could have it do a callback to a script on your site that does a tally for you. The app should, obviously, only call this on the first run (but, depending on how you implemented it, would probably be called on each refresh of the app's cache/data). If you don't have a service that needs registration, you could have it done in the background.
Not possible by default. The only figures that do exist are only updated daily at most.
You would need to devise your own way to count downloads such as requiring your users to register on your own service.