As at August 2015, the 'Drive API for Android' is not functioning as (loosely)documented, is effectively broken. The main sore points are as follows:
1) An app sharing the same APP_ID and logged in with the same Google User is meant to be able to find and access the same files as Google indicate (e.g. appX on device1 creates a folder named 'blahblah' (where no 'blahblah' folder already exists in the User's Drive), appX on device2 should be able to find that folder and upload/download files from it also...however this is not the case (or if it does work, it is intermittent and mostly not working at all)). This remains the case even after (many) requestSync calls and over 72hours of allowing Drive to sync itself.
2) A trashed folder is not observed as trashed, even after a requestSync call has succeeded. Such a trashed folder will still have isTrashed==false.
3) A permanently trashed folder (i.e. it is GONE from Drive, it is never coming back). Can still be found and "successfully" have folders and files created within it, however writing to such a file's contents will always yield a failure in Completion Event Service. Again, such a folder will still have isTrashed==false (which is abysmal).
Bug reports have been lodged (thanks to #DalmTo for the link) via: https://code.google.com/a/google.com/p/apps-api-issues/issues/entry?labels=Type-Defect,API-Drive
https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=4003
https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=4004
SO, the question: know a way around these issues?
UPDATE:
I've narrowed these problems down to my personal Google account (or my personal Drive, which has many, many files in it). That suggests these issues are symptoms of or closely related to https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3905
I can give you some points regarding the issue 1/ (syncing on multiple devices running the same app). I've been pointing out this already in April 2014 without satisfactory answer (actually resounding silence). So I switched back to the REST API and handled everything myself (using syncadapter, service, ...). The REST's algorithm is:
create/update/delete/ .... (execute() method)
dispatch resource ID ('id'+message) using GCM to other devices
let other devices deal with the change through the REST API (again, in service)
I've re-visited the GDAA a few times since and never got satisfactory results (requestSync). Finally, I got half-way happy when started to use 'completion events' (a year later, needless to say).
Again the algo is:
create ....
get ResourceId from completion
dispatch 'ResourceId'+message using GCM to other devices
let other devices deal with the change through the GDAA (using the ResourceId)
... and the point is:
During the time I was trying to make it work, I finally realized that the GDAA is not well suited for all applications (like the one we're discussing here). The GDAA goes through all kinds of hoops and loops to make the online/offline state transparent and at the same time to cache data and optimize network traffic, battery use, ... It creates latency, unpredictable states...
... so, in the end I stopped blaming the GDAA for not being a swiss-knife and do everything everybody ever dreamed up. It is up to the developer to FULLY understand the advantages / drawbacks of a toolbox he/she is using and decide upfront which tool to use. I know, the docs do not spell it out and believe me, I myself got caught in Magnus's excitement. I still remember pinoyyid's warning in January 2014, telling me not to jump in too early.
Good Luck
As per your response on the issue tracker, we believe this is an issue with sync for your particular account, potentially related to this issue. We'll continue discussion of this issue on the issue tracker.
Related
Let's say somebody managed to access my application's source code and injected his code, changed something, or used DvMap is it possible to detect this?
EDIT: changed "modifications" with "unwanted modifications" in title. Since it's obvious to detect changes especially if you are using VCS.
1. Use source control
Every time you make a change to your application's source code, commit / check it in to a source control service like Git, Mercurial or Team Foundation. If anyone changes your code, source control will inform you that you have changes that were not stored in source control - it will show you not only that the code was edited, but what the edits were (what was added, moved, deleted etc).
2. Use checksums
Every time you deploy your application to an .apk file, run a checksum on it and save the checksum value to a few locations with the version number. If you like, even write down the first and last 4 characters in the checksum for the version so that if anyone changes the checksum on your website etc to match their hacked version, you will know. You can't edit paper
3. If you have other contributors to your project, heavily document and review each other's code
This not only prevents bugs and silly mistakes being pushed to live / production builds, but it also stops anything getting passed someone who notices an intentional flaw. In the event someone adds a back door, it will be noticed.
4. Take basic security measures on your devices
This is a basic yet overlooked part of security. Essentially, lock your computer when you aren't using it. Use long and secure passwords, or a good password manager like LastPass or KeePass. Don't hand your passwords out to anyone, at all. Don't click on any suspicious links or open files that you don't trust. You get the idea.
I've been noticing for the last month or so that users of my Android app are receiving partial updates. What I mean by this is that their version is up to date and has most of the features that I had made live, but at the same time would still have code that I had changed weeks earlier. This did not affect users that did a clean install though, just the 99% that probably update an app like a normal user would. I could see how this could easily be caused by a lapse of concentration while using "git add" however I've exclusively used "git add -A" for probably the last two months so this is not the case. Recently I got fed up enough with it that I purposely changed some of the log statements here and there just so that if I ran into another user who's phone had partially updated, I could check it out and see what files were up to date or not. Amazingly, I found a mix and match of updated and outdated files. I contacted Google via chat and they said that they would transfer me to an email conversation with a technical representative, but I haven't heard back yet. Has anyone else encountered this issue and how would you go about solving this?
I'm trying to install Kik Messenger twice. I have two accounts and don't like to log out because I lose all of my conversation history. I'm currently using Titanium backup's profile feature, which is a very nice fix, but it's still a pain having to switch back and forth between profiles. I might be looking for "perfect" when perfect doesn't exist. I am completely new to modding apks and Android in general, all of my work on this so far has been "trial and error". Anyways, here's what I have:
I have the Google Play version of Kik installed on my phone. I have extracted that app and modified the package name successfully using apktool. However, when I try to install, I get an error saying something about duplicate provider authority. So I did some research and learned that I'm supposed to edit this part of the AndroidManifest. So I have played around with that a little bit and after I change the authorities, I am able to install the modded app. However, it crashes immediately.
Does anyone know how to fix this problem with the provider/authorities?
The issue you're hitting is that the app has registered certain classes to handle particular events. These need to be unique across all installed apps and point to existing classes in the app that will perform some activity with the supplied information.
You bypassed the safety check when installing by changing the defined handlers in the Manifest but that didn't really fix it as they still need to actually point to a valid, working class that can handle the requests/events.
You would need to decompile, rename the classes involved and all references made to them and recompile the whole app to really fix the problem. However, I'd assume that it would likely be against the license. If the code is open source then it wouldn't be too big a task to rename some classes & packages then build the app. If it's closed source then it is a harder task.
What you can do is either set up your device to use multiple accounts (the OS not the app) as each user has a separate data storage and preference location that should allow you to have two configurations. Or you can request that the developers include some sort of multiple account handling or easy account swap feature.
I've written a program that, when completed, I plan to add to the Android Marketplace. I have given many files as features for users to store information and reload later, and while debugging, I've noticed the files tend to get deleted when I update the code after a long while (like a few days spread apart--for some reason, it doesn't happen when I update the code often, like every hour when I'm adding new features and testing them out). Note that I use a real phone for testing and not the emulator. What I'm wondering is, will the files get deleted after each release of the app?
I really don't want users to lose their stored information on every update or bug fix I provide, so if that is the case, is there a way around this?
Nope the files doesn't get deleted automatically, but it depends upon where you are storing the files. If the user deletes the app the files associated with it will get deleted too. But in case of an upgrade, No! normally it won't.
In case you are using SQLite for storing data, there is a proper way to handle upgrade there.
So, I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk (via adb install -r, and presumably when a user gets an update that has been pushed to the Android market). Is there any way to force an application's data to automatically be cleared upon update of the app? I realize there are different ways that data could be stored, but I just need to essentially simulate an invocation of the "Clear Data" button that'd you find when browsing to the application in the "Manage Applications" section of the Settings (i.e. I just want all data gone).
I am an Android noob and am doing minimal Java coding on this project, so I am basically looking for the simplest solution here. I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this? If so, what's the simplest way to do so?
Thanks!
Is there any way to force an application's data to automatically be cleared upon update of the app?
No, at least for my definition of "automatic".
I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this?
I'd name it lastKnownVersion, but otherwise this approach seems sound and probably is your only viable option.
If so, what's the simplest way to do so?
Ummm...do exactly what you said. Use Java I/O (storing the file somewhere inside of getFilesDir()), or SharedPreferences.
Bear in mind, though, that your users may get rather frustrated if you blow away their data on an app update. Personally, I'd rather we find a better solution to your original problem ("I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk").