Searched refs:leak (Results 1 – 12 of 12) sorted by relevance
| /frameworks/base/core/java/android/app/ |
| D | LoadedApk.java | 641 IntentReceiverLeaked leak = new IntentReceiverLeaked( in removeContextRegistrations() local
646 leak.setStackTrace(rd.getLocation().getStackTrace()); in removeContextRegistrations()
647 Slog.e(ActivityThread.TAG, leak.getMessage(), leak); in removeContextRegistrations()
649 StrictMode.onIntentReceiverLeaked(leak); in removeContextRegistrations()
669 ServiceConnectionLeaked leak = new ServiceConnectionLeaked( in removeContextRegistrations() local
672 leak.setStackTrace(sd.getLocation().getStackTrace()); in removeContextRegistrations()
673 Slog.e(ActivityThread.TAG, leak.getMessage(), leak); in removeContextRegistrations()
675 StrictMode.onServiceConnectionLeaked(leak); in removeContextRegistrations()
|
| /frameworks/base/core/java/android/view/ |
| D | WindowManagerGlobal.java | 346 WindowLeaked leak = new WindowLeaked( in closeAll() local
349 leak.setStackTrace(root.getLocation().getStackTrace()); in closeAll()
350 Log.e(TAG, "", leak); in closeAll()
|
| /frameworks/base/location/lib/ |
| D | README.txt | 30 API that does not leak the internal classes.
|
| /frameworks/base/docs/html/tools/debugging/ |
| D | debugging-memory.jd | 35 development (which you should), you still might leak objects or introduce other memory bugs. The
102 continues to increase and doesn't ever seem to get smaller, you could have a memory leak.</p>
433 new tab that traces the references to that object which is causing the alleged leak.</p>
479 the heap. However, the smaller the leak, the longer you need to run the app in order to see it.</p>
481 <p>You can also trigger a memory leak in one of the following ways:</p>
484 activity states. Rotating the device can often cause an app to leak an {@link android.app.Activity},
|
| /frameworks/base/docs/html/training/basics/activity-lifecycle/ |
| D | stopping.jd | 80 you use {@link android.app.Activity#onStop()} to release resources that might leak memory.</p>
186 last chance to clean out resources that could lead to a memory leak, so you should be sure that
|
| D | starting.jd | 267 potentially leak memory if not properly closed, you should kill them during {@link
|
| /frameworks/base/docs/html/training/contacts-provider/ |
| D | retrieve-details.jd | 267 leak. For example:
|
| D | retrieve-names.jd | 494 recycle the {@link android.database.Cursor}, which causes a memory leak. For example:
|
| /frameworks/base/docs/html/guide/topics/resources/ |
| D | runtime-changes.jd | 126 leak all the views and resources of the original activity instance. (Leaking resources
|
| /frameworks/base/docs/html/training/articles/ |
| D | security-tips.jd | 210 <p>Do not leak permission-protected data. This occurs when your app exposes data
408 could inadvertently leak user data to other applications.</p>
|
| D | memory.jd | 195 it's actively performing a job. Also be careful to never leak your service by failing to stop it
|
| /frameworks/base/docs/html/tools/sdk/ |
| D | tools-notes.jd | 1046 <li>Fixed memory leak in the emulator.</li>
|