We now write battery history directly into a buffer, instead of
creating objects. This allows for more efficient storage; later
it can be even better because we can only write deltas.
The old code is still there temporarily for validation.
Change-Id: I9707d4d8ff30855be8ebdc93bc078911040d8e0b
This seems simpler and more contained, and I think the comment explaining
why hoop-jumping is necessary is a bit clearer now.
Change-Id: Ief4afd7cbb42188ed835fce23e497520bdb753a8
* commit 'a4b76ff4911538f01e92af2f3fa3f4016ad0e290':
Fix access point parsing: reset static link property after parsing static ip setting Fix removeConfiguredNetwork: add sleep between remove configured network and disable wifi
* commit 'd69ec89f5d31064174d79e2e77504814629cffa6':
Fix access point parsing: reset static link property after parsing static ip setting Fix removeConfiguredNetwork: add sleep between remove configured network and disable wifi
* commit '46b59ef01be530a6bbe3f0e9a2bed27de9985f40':
Fix access point parsing: reset static link property after parsing static ip setting Fix removeConfiguredNetwork: add sleep between remove configured network and disable wifi
Use ScopedUtfChars (fixes a leak in TrafficStats, and fixes a crash in Wifi in
a case where GetStringChars could have been called with a pending exception).
Change-Id: I3465ff392b4038dfdafa6af80ec1314cc6d6a11c
You can remove sub-tasks inside of a task, or an entire task.
When removing an entire task, you can have its process killed
as well.
When the process is killed, any running services will get an
onTaskRemoved() callback for them to do cleanup before their
process is killed (and the service possibly restarted).
Or they can set a new android:stopWithTask attribute to just
have the service automatically (cleanly) stopped at this point.
Change-Id: I1891bc2da006fa53b99c52f9040f1145650e6808
Don't keep unused global references to classes, don't throw exceptions
when an exception is already pending, and fix a (harmless) misunderstanding
about how GetStringChars works.
Change-Id: Ie445036f057daa8a1c76aceb7bad2a84fb81d820
We can help you with that.
Note also that getParcelFileDescriptorFD did no such thing. All its callers
were passing in a regular java.io.FileDescriptor and expecting the int. No
ParcelFileDescriptors involved.
Change-Id: Idc233626f20c092e719f152562601f406cc1b64a
Just use jniThrowException instead. Note that it would be trivial to throw
seemingly more appropriate exceptions (NullPointerException and
OutOfMemoryException in particular), but I'm only attempting to preserve
existing behavior here.
I also found shadowing bugs in some of the special-case functions, which
would previously always have leaked memory.
This also moves an accidental change to a generated file (ActivityThread ->
AppGlobals) into the generator, so it won't be overwritten in future.
Change-Id: Iab570310b568cb406c60dd0e2b8211f8a36ae590
Some API stubs for managing users and storing their details.
List of users is stored in an xml file.
Each user's properties are stored in a separate xml file.
Some unit tests for modifying the XML files.
Change-Id: If2ce2420723111bd426f6762def3c2afc19a0ae5
