Our getNanoAppInstanceInfo() method returns incorrect information
for several fields in many cases. We're too late in the release
cycle to fix the core of this issue, but we can at least document
it so users aren't surprised.
Bug: 30944457
Change-Id: I9330c3b77d08c36befbe20258c6cc45dc640f103
Made changes to AccessPointPreference to prevent
it from ever setting a empty icon to reduce the
jittering from elements all changing at once.
Bug: 29979747
Change-Id: If432aed1d55b37cf3d48074275f8b3dc0584f884
(cherry picked from commit 45a1594247)
There's no API to set mContextHubId, but testMatch() uses this.
We can't add API at this point of the release cycle, so instead
we default mContextHubId to HUB_ANY, which makes it always match.
Bug:30018518
Change-Id: I4e08afc65889dc109a4da1bd99a027345da865ca
We're squeezing a 4-byte signed value to 1-byte. The naive
(implicit) cast we were using could flip this value from positive
to negative, or vice versa, and completely change the meaning
of the result.
API freeze prevents us from fixing this properly at the moment,
but we use a less naive approach to truncate this value, maintaining
its meaning and logging when we've changed the value.
Bug:30829863
Change-Id: I0e80af9b192066fdf36fee565a4587eb75a5ea7b
Most notably, the loadNanoApp() claimed it was returning the
nano app instance handle on success, when it actually was just
returning 0 on success.
Bug: 30475803
Change-Id: I436255f0103a743a02f40c41ee4c6f653d007d89
The suggestions list in the summary page of the
settings app could sometimes cause a crash due to
an uncaught exception. Tis fixed now.
Bug: 30656840
Change-Id: If79f53e6a8c17a81653228d613797e94c473d410
(cherry picked from commit 60d92b3b83)
We now ask for the appId the user requested, instead of asking
for no apps (asking for NANOAPP_VENDOR_ALL_APPS without pairing
it with any vendors results in no apps).
Bug: 30829899
Change-Id: I896af60814d55c7f8cb298c9142212bac5b06995
Our logs would show us loading apps twice, when in reality we
load them once, and then update our caches with the app
version later.
There are other issues around how this code works (for example,
b/30970527), but this is an appropriate approach at this
stage of the release.
Bug: 30836667
Change-Id: I2e2a65bc8a2ef4d1703df0a0586a8ed251607af7
This value is used to convert ACTION_SCROLL axis values into raw
pixel distances.
CP of ag/1333603 from master to feldspar-dev. New method is @hide and
@SystemApi in this version. In master, it's part of the new public
API, but feldspar will launch before O.
Change-Id: I5ee73ebcd183c43939ae8aa157e88489e05d4760
Our code was sometimes using 'uint32_t' and mostly using 'int'
to represent these custom handles. It was also passing this
value, as a byte stream, to the Java layer.
In the Java layer, this is an 'int', and thus we change all
of our usages to be 'jint' here. However, we still pass it
as a byte stream, since we're too late in the release cycle
to change the API. But now this is at least a consistent
size for the code.
This code still suffers from hub handles being inconsistent
with their types, but we leave that for another bug (b/30958512).
Bug: 30806218
Change-Id: I8d9ae8b9519f399d6723cf96293d84a2f5bd9cce
When we unloaded a nanoapp, we weren't updating the cache of
nanoapp information at the ContextHubServer java layer. Also,
we were leaking the handle.
We fix both of these by invoking the shared delete_app_instance()
function which properly handles all of this.
Furthermore, we allow delete_app_instance() to accept a nullptr
for the JNIEnv, and fix invalidateNanoApps() so that it won't
crash if it's unable to connect to the JVM.
Note that our Java communication in general here should be
cleaned up, but we're too late in the release cycle for
that, and leave that for b/30961119.
Bug: 30951974, 30968860
Change-Id: Ibb07666a8d54618bddaa3eaf36f9578926eb2b0f
