Tag Archives: activity

Manifest merger failed: android:exported needs to be explicitly specified for . Apps targ

Manifest merger failed : android: exported needs to be explicitly specified for. Apps targeting Android 12 and higher are required to specify an explicit value for android:exported when the corresponding component has an intent filter defined. See https://developer.android.com/guide/topics/manifest/activity-element#exported for details.

Solution: In the Activity with the intent, add android:exported="true"

<activity android:name=".MainActivity"
            android:exported="true">
      <intent-filter>
          <action android:name="android.intent.action.MAIN" />

          <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
</activity>

0xc0000005: an access conflict occurred while reading location 0x00000020

0x in.exe… Unhandled exception at: 0xC0000005: Access conflict occurred while reading position 0x00000020

Error: : PostMessage (AfxGetMainWnd () – & gt; M_hWnd, UM_XX, 0, 0);

or: : sendMessage (
AfxGetMainWnd()-> M_hWnd, UM_XX, 0, 0);

How to solve it?
Verify that afxGetMainWnd () returns NULL

int k = (int)(& (((CWnd*)NULL)-> m_hWnd));
The value of k is 0x20

In general: afXGetApp ()-> GetMainWnd (); AfxGetMainWnd() is used only on the main thread;

How: foreground thread and background thread, afxGetApp ->; GetMainWnd() differs from AFXGetMainWnd ()

AFXGetMainWnd () is an example of a window handle that can be used to retrieve a window handle. AFXGetMainWnd () is an example of a window handle that can be used to retrieve a window handle. Clever you must have already understand, if you have been tracking AfxGetMainWnd () call, will find that it earned a AFX_MODULE_THREAD_STATE threading module save active threads in the window handle, and a background thread since no window, then obtains the window handle is you from??(maybe someone’s understanding of the background is not display window, even with all the window, as long as it doesn’t show is a background thread, strictly speaking is not the case, the window is mainly used to interact with the user, a window is hard to avoid jam, And the background thread is often used to carry out some behind the operation or processing, is through the foreground information or data to carry out the corresponding operation, if the window is hidden to talk about what information transfer?The case can not be done in the background like other threads. The key is to know the difference and how to use it.)
AfxGetApp()-> GetMainWnd () is the main window handle, no matter in that thread calls are no problem, because it is first obtained the main thread handle, to achieve the main thread of the active window (such as switch view can lead to replacement, I am not sure this kind of circumstance), if there is no active window is the main window, any program must have a main window, so it calls there is no problem, if you want to achieve the program’s main window suggested AfxGetApp () – & gt; GetMainWnd().
Note that the console program has no window and its window handle is always 0. Second, the background thread is actually a desktop control program, just not the main thread. Also, threads created using functions such as API CreateThread cannot generate CWinThread objects. So if you want to use CWinThread object function, and some of the global function, as AfxGetMainWnd (), you must use CWinThread object CreateThread function, or use the AfxBeginThread () function creates a thread, or may be an error, because the MFC to the management of the thread is done through the CWinThread object, it is not hard to see through the tracking code below you. I remember that there was a predecessor once mentioned this problem, but I do not know whether it understands the reason
Here is the trace code:
_AFXWIN_INLINE CWnd* AFXAPI AfxGetMainWnd()
{ CWinThread* pThread = AfxGetThread();
return pThread! = NULL ?pThread-> GetMainWnd() : NULL; }

CWinThread* AFXAPI AfxGetThread()
{
// check for current thread in module thread state
AFX_MODULE_THREAD_STATE* pState = AfxGetModuleThreadState();
CWinThread* pThread = pState-> m_pCurrentWinThread;
// if no CwinThread for the module, then use the global app
if (pThread == NULL)
hread = afxGetApp ();
return pThread;
}
You can see that calling afxgetMainwnd () on the main thread is not a problem (except for console programs) because it returns the main thread handle if the fetched thread handle is empty.
_AFXWIN_INLINE CWinApp* AFXAPI AfxGetApp()
{ return afxCurrentWinApp; }

CWnd* CWinThread::GetMainWnd()
{
if (m_pActiveWnd ! = NULL)
return m_pActiveWnd;// probably – place in active
// when not inplace active, just return main window
if (m_pMainWnd ! = NULL)
return m_pMainWnd;
return CWnd::GetActiveWindow();
}
I don’t need to worry about AFXCurrentInApp.
Hey hey, all finished, if your program exists similar to the above problems can be sure to change back oh.

Android avoids memory leak: reasonable use of getcontext() and getapplication ()

To conclude:
GetApplicationContext () can fetch the Application object, and getContext() is generally considered to return an Activity object (which, of course, is not actually limited to the Activity). 2. For Application, you can see from the Manifest file that an Application typically has only one Application node. Application is just an Application, that is, as long as the current Application is still running, it can get to the Application object. 3.Application is a long reference, and Activity is a short reference. Application is suitable for storing objects that need to be read repeatedly, such as the user’s username and password, the current Settings of the Application, and so on. When an Activity is applied to the current active form, such as displaying a Dialog, or creating a new View, the context object passed in should be the current Activity, not the Application.
    
Android applications limit heap memory to 16M (note: heap memory is also related to device performance; available heap memory for high performance devices may be 24M or more), with phone functions taking up a portion of the heap and developers having very limited access to it. If you’re not going to run out of memory, your application should use as little as possible so that other programs don’t get killed when they run. The more applications the Android system can hold in memory, the faster users can switch between applications. As part of my work, I researched memory leaks in Android applications and found that most of the time it was the same problem: holding a long reference to the Context.
In Android, Context is used for many operations, but mostly to load or access resources. This is why all Widget components receive a Context parameter in the constructor. For a typical Android Application, there are usually two contexts, namely Activity and Application. Developers often need the context to select an Activity when passing between classes or methods.

this indicates that Views have a reference to the entire Activity, so anything in your Activity will be held by Views, which are generally held by the view hierarchy and its corresponding resources. So, if you give away the Context, you’re giving away some memory. If you’re not careful, it’s very easy to reveal an Activity.
when the screen direction changes, the system will save its state by default, destroy the current Activity, and create a new one. To do this, Android reloads the application’s UI from resources. Now let’s say you’re developing an app that contains a lot of bitmaps, and you don’t want to load bitmaps every time you switch screens. So the easiest way to do this is to use the static static field.