I just came upon this by accident
http://officialandroid.blogspot.co.il/2012/09/the-benefits-importance-of-compatibility.html
This seems like the right approach, but my own experience is that the
Android reality is very far from this ideal.
I've heard about the CTS.
The question is - are
Yes. To install Google Play or Google apps, you absolutely are
required to pass the CTS.
But, from your discussion, the CTS obviously doesn't test all parts of
the Android platform: it's just a test suite.
Kris
On Wed, Jul 31, 2013 at 11:06 AM, Omer Gilad omer.gi...@gmail.com wrote:
I just
On 07/31/2013 05:17 PM, Kristopher Micinski wrote:
Yes. To install Google Play or Google apps, you absolutely are
required to pass the CTS.
But, from your discussion, the CTS obviously doesn't test all parts of
the Android platform: it's just a test suite.
Yes, and never will.
It may be a
Just because a test suite doesn't cover all possible behavior doesn't
mean stricter enforcement wouldn't help developers.
Test suites don't cover all of the codebase by definition, that's why
they're called test suites :-)
So I'm in favor of setting up a tracker for device bugs, but that
doesn't
Since pretty much everyone agrees that the CTS misses things...
Wouldn't it be worthwhile to not only track device specific issues, but to
also add tests to a fork of CTS?
Google might then accept those enhancement, or might not, it would still be
helpful in any case.
-- K
On Wednesday, July
Hey Mike I still didn't get answers to my questions about this service...
What are the remote devices that the code is running on? Do I need to
instruct a user to install this on his own device?
On Monday, July 29, 2013 8:56:12 PM UTC+3, Mike wrote:
Use my App, you can run code on remote
Well, after i started encountering such issues i just LOADED my app with
debugging information, like, seriously redonkulous amounts of logging.
There's nothing the app didn't log, sorted with tags and extra information
to say exactly what is doing on and why. It was easier to fix bugs of even
.I've decided to move to iOS development, and the only way to convince me
otherwise is to give me a decent, reliable way of dealing with fragmentation
There isn't any reliable way of dealing with fragmentation - devices and
platform bugs has to be workaround (if possible) or device marked
You can run most of the Android API, you can even hook up and listen to
BroadCast events.
There are few limitations, one is the callback, you can not use
startIntentWithResult .
User need to download the App from play store, and install, log in.
On Sunday, July 28, 2013 5:30:57 PM UTC-4, Omer
Use my App, you can run code on remote device, not just read logs:
https://cloudshellapp.appspot.com/
https://play.google.com/store/apps/details?id=com.cloudshell
The App will allow you to run code on remote Android phones,
so you can fix the bug on the phone you do not have physical access to.
Wrote a lengthy response but my browser decided not to post it, so here's
the short version:
- That's a known problem with android development, it was obvious about a
couple of months after it came out. when the premise of the system is to be
open and as varied as possible, this kind of issues
I wrote an free App and web site to help myself on the Android
fragmentation problem:
https://cloudshellapp.appspot.com/
https://play.google.com/store/apps/details?id=com.cloudshell
The App will allow you to run code on remote Android phones,
so you can fix the bug on the phone you do not have
Does anyone have a workaround for one of the bigger problems of this mess:
users will blame your app and write bad reviews?
That sounds like a joke, but really, has anyone had success just telling
users sorry, Samsung's fault :(?
Would be a shame to lose sales because of the vendor's problems.
I don't have one, can only share more pain :)
Most users are very reluctant to accept explanations like that, because the
devices are much more expensive than the typical Android app.
It's just psychology: I paid $xxx for this, and it's 'top of the line', do
you mean to tell me there is
What you wrote is the obvious part of what I do - test with beta users. I
agree that this is a must.
The problem is, sometimes it's impossible to debug what you find.
When the issue is not a simple crash stack trace - but rather some
behavior, or display issue, you can't just keep ping-ponging
That looks innovative, I'll definitely dig into this...
How versatile is this solution? Can you run only a select part of Android
APIs, wrapped by your script?
How is the distribution being done (like, where are all those devices that
run the test code)?
On Sunday, July 28, 2013 10:05:54 PM
The best workaround I know for that is to filter devices on Google Play
console.
Yes, you lose tons of customers, but at least you don't get 1 star reviews
like IT SHOWS BLACK SCREEN ON MY CRAPSUNG S4 CRAP EDITION, DON'T DOWNLOAD
On Sunday, July 28, 2013 11:51:32 PM UTC+3, Thomas Jakway wrote:
So in this case, how does a subscription based test service not help
you? I'm not saying that a concrete one exists, but I think this kind
of debugging service (or coop, essentially) would be a good tool. You
include a time metric, do some tasks to help other developers', and
they do some work
With all this talk I still haven't seen an example of a testing service
that can actually help me...
Got any links? Anything with a reasonable price that can ease the pain (and
that you used for yourself)?
BTW, I have worked in the past with some of those remote device providers
(like
I didn't posit that there were concrete things you could go out and
buy right now, so apologies if I misphrased. I know a group who works
on a research project which does basically this, but there's no word
on whether it will be open source any time soon. I think the idea is
what I just
A testing service still -- focuses only on specific device models, assuming
deterministic failures, ignoring weird shit that can happen on seemingly
any of them, even the good ones.
Going back to my Youtube video of Google Maps causing a device reboot:
Is the Galaxy Nexus a bad device? No.
I'm amused by what came to my mind because of what you wrote - I thought of
having a website like that for mutual testing between Android developers.
We can call it DroidSurfing (like CouchSurfing), and the point is simple
- registered like-minded Android developers let your code surf on their
Absolutely, I think I made pretty clear that it wasn't intended as a
solution. (E.g., my many previous posts agreeing with you and
admitting it was a numbers game.)
But that being said, if it's a numbers game, the idea gets you a lot
closer to it than testing on the n devices you own.
To be
Yes, making a system like this work in the real world requires many
other things, including proper incentivization (do the developers get
back a proportional amount of what they put in), metrics for
accounting, adjustment for device ownership stats (people with less
common devices will be unduely
24 matches
Mail list logo
