What's the "Dot" for When Registering an Activity

Leading dot in android:name really required?

Omitting the dot and not fully qualifying the package/class name will work if and only if the specified class is not part of a subpackage within your application.

If your application package name is com.example.myapp, and you have an activity class com.example.myapp.MyActivity:

android:name="MyActivity" will work.
android:name=".MyActivity" will work.
android:name="com.example.myapp.MyActivity" will work.

But if you have the same application package and an activity class in a subpackage within your source tree such as com.example.myapp.myactivities.MyActivity things change.

android:name=".myactivities.MyActivity" will work
android:name="com.example.myapp.myactivities.MyActivity" will work
android:name="MyActivity" will not work
android:name="myactivities.MyActivity" will not work

3 doesn't work because that will infer that the class name you mean is actually com.example.myapp.MyActivity like in the first example above. A class with this name won't be found and you'll get an error.

4 doesn't work because it looks like a fully qualified class name, that is the system will interpret it to mean that myactivities.MyActivity is the fully qualified name itself, not the real name of com.example.myapp.myactivities.MyActivity.

You need the leading dot here to clarify that you're using a relative path, not an absolute path. If you specify just a class name with no package info at all, the system infers that the class is at the root of your application package hierarchy.

What does a leading dot in an android:name mean?

Look at this.

The name of the Service subclass that implements the service. This should be a fully qualified class name (such as, "com.example.project.RoomService"). However, as a shorthand, if the first character of the name is a period (for example, ".RoomService"), it is appended to the package name specified in the element.

What's the correct syntax to define an activity in manifest file

dot means your package name. It's more short type of declaration.

If you define a subclass, as you almost always would for the component
classes (Activity, Service, BroadcastReceiver, and ContentProvider),
the subclass is declared through a name attribute. The name must
include the full package designation. For example, an Service subclass
might be declared as follows:

<manifest . . . >
     <application . . . >
         <service android:name="com.example.project.SecretService" . . . >
             . . .
         </service>
         . . .
     </application> 
</manifest>

However, as a shorthand, if the first character of the string is a period, the string is appended to the
application's package name (as specified by the element's
package attribute). The following assignment is the same as the one
above:

<manifest package="com.example.project" . . . >
     <application . . . >
         <service android:name=".SecretService" . . . >
             . . .
         </service>
         . . .
     </application> 
</manifest>

When starting a component, Android creates an instance of the named subclass. If a subclass isn't
specified, it creates an instance of the base class.

http://developer.android.com/guide/topics/manifest/manifest-intro.html Declaring class names

How are values compared when appending a dot to an instruction

The dot means that the CR0 flags (bits 0..3 of CR) will be updated based on the result of the instruction.

cr0 is used for the results of fixed-point computation instructions, which use non-immediate operands (with a few exceptions). The result of the computation is compared with zero, and the appropriate bits are set (negative, zero, or positive).

To indicate in a computational instruction that you want it to set cr0, you simply add a period (.) to the end of the instruction. For example, add 4, 5, 6 adds register 5 to register 6 and stores the result in register 4, without setting any status bits in cr0. However, add. 4, 5, 6 does the same thing, but sets the bits in cr0 based on the computed value.

CR0 bits:

0: Negative (LT) - This bit is set when the result is negative
1: Positive (GT) - This bit is set when the result is positive (and not zero)
2: Zero (EQ)     - This bit is set when the result is zero
3: Summary overflow (SO) - This is a copy of the final state of XER[SO] at completion of the instruction

(source)

BroadcastReceiver not called when registering from manifest

Since Android Oreo, receivers must be registered in runtime using

context.registerReceiver(receiver, intentFilter);

to receive implicit intents

You can still receive explicit intents and some special implicit actions, as boot_completed or locale_changed for example

Android: Activity not registered in the manifest

I've got the solution. Today I felt motivated enough get my hands on this project again and tried to port the project to a Linux-distribution (which led me to the conclusion that Linux is a pain in the ass for Android developent) as well as to integrate it "line by line" to a new Android project.

I used to implement String- & Integer-interfaces with certain constants and values (e.g. 0x00 for "visible"). Unfortunately, Android seems to have trouble with interfaces and activity-classes. Removing the interface and making static references onto the constants made the emulator get rid of the problem.

public class MyActivity extends Activity implements Options // [...]
Btn.setVisibility(VISIBLE); // bad idea

public class MyActivity extends Activity // [...]
Btn.setVisibility(Options.VISIBLE); // good idea

Hopefully this is gonna help at least someone searching for this issue.

What exactly does the C Structure Dot Operator Do (Lower Level Perspective)?

When you use the . operator, the compiler translates this to an offset inside the struct, based on the size of the fields (and padding) that precede it.

For example:

struct Car {
    char model[52];
    int doors;
    int GasMilage;
};

Assuming an int is 4 bytes and no padding, the offset of model is 0, the offset of doors is 52, and the offset of GasMilage is 56.

So if you know the offset of the member, you could get a pointer to it like this:

int *GasMileagePointer = (int*)((char *)&carInstance + offsetInBytes(GasMile));

The cast to char * is necessary so that pointer arithmetic goes 1 byte at a time instead of 1 sizeof(carInstance) at a time. Then the result needs to be casted to the correct pointer type, in this case int *