Status Update
No update yet.
Comments
tj...@google.com
I am not sure I understand the use case. how can the benchmark be code to real world scenario when it's not possible to do right now ? which scenario is it ?
In any case, since this would be for benchmarking, this would clearly not be available through the public DSL. We should find a semi-private way of doing this (maybe the private variant API object could offer that functionality for instance or a property).
tj...@google.com
We want benchmarks to measure code after Progaurd / R8, but it's not possible to turn that on for androidTests in library modules at the moment (to my knowledge?)
Benchmarks are also a public facing thing, but we have a plugin to help configure gradle builds for our users, so if support for this ends up in a private API, we could try to keep those usages localized to our code perhaps.
ta...@monzo.com
Any update on the status of this request and when it can be supported?
Thanks,
Amanda
tj...@google.com
this is not part of our OKR at this point so we are not talking soon. at first glance, we would need to simulate usage patterns to minify against and such, this seems substantial amount of work. there are not a lot of library module that have android tests, most only rely on unit-tests.
how important is this ? we are out of PM right now but I suspect the next step will be to negotiate with J. Eason and xav@ to scale a priority level.
Description
AppSearch module used:
androidx.appsearch:appsearchandroidx.appsearch:appsearch-compilerandroidx.appsearch:appsearch-local-storageAppSearch version used:
1.1.0-alpha07Devices/Android versions reproduced on: A variety of devices, nothing stands out
Our app has a feed-like functionality. Roughly the logic is that when you first log into the app, it will try to sync the whole feed history. It downloads and saves feed items in chunks, and stores them in our database. When you reopen the app, it will only try and sync the latest feed items.
I've introduced AppSearch in our app, so that feed item information is also stored (as documents) in AppSearch together with our DB. For now we're not using this information, my plan is to leave this out for some time, so that people have a lot of indexed feed items by the time I go and try to use them.
In general the rollout went well - we have about 2 million WAUs, and each of those can have thousands of feed items, so I was expecting a few niggles.
We are using the
AppSearchSession.putAsync()method, and notices some failures in production showing up inside theAppSearchBatchResult.A lot of these have to do with the device storage space running out. Here are a couple of the error codes and messages:
Couldn't grow file /data/user/0/co.uk.getmondo/files/appsearch/document_dir/usage_store/usage-scoresInsufficient disk space to create prefix property!These all make sense, and are expected. I'm not worried about them.
But we've also noticed some exceptions coming that don't seem to have anything to do with disk space:
Key cannot contain a null character '\0'Failed to read from key mapperFailed to write proto metadataOur error reporting solution (Sentry) also includes disk space information with every error, and for these cases, all the users had plenty of free disk space.
Specifically about the key, I'm 100% sure there's nothing wrong with what we're using as a document id. It's always a unique string, which doesn't contain a null character.
We are seeing about 10 of these per day. Unfortunately I don't have a lot more to go on. I haven't found a way to reproduce these, and there's no documentation about them so I don't even know where to start. Are these expected? Are they not? Could it be related to the way we configure AppSearch, and it's something that can be fixed, is it a problem in the library, or is it something else?