Choose Stable Android Element Selectors for Phoma Flows

Why Android selectors break after an app update

Phoma lets you build automation flows visually on your Windows PC and run them on Android phones over USB or Wi-Fi. Every step that touches the screen—tap, type, read text, wait for an element—relies on an element selector. When the app you are testing updates, the screen can look identical to a person while the underlying layout changes enough to break your flow.

A button that was the third button on the screen might become the fourth. A resource ID might change from login_button to sign_in_button. Text that said "Submit" might change to "Continue" or be translated into another language. If your flow was built around a brittle selector, the step fails and the whole run stops.

This guide shows how to inspect an Android app's UI tree in Phoma, choose selectors that survive updates, and verify them before you save a flow.

Prerequisites

• Phoma installed on a Windows PC
• An Android phone with USB debugging or wireless debugging enabled
• The phone connected to Phoma and visible in the device list
• The app under test installed on the phone

If the phone does not appear in Phoma, check the USB cable, driver installation, and the "USB debugging" authorization dialog on the phone before continuing.

Step 1: Open the element inspector

Start Phoma and select the phone you want to inspect. Open the screen in the app that contains the element you want to act on. Launch Phoma's element inspector from the device toolbar.

The inspector captures the current UI Automator tree: a hierarchy of every visible element on the screen. Each element exposes attributes such as:

• resource-id: the internal ID assigned by the app developer
• content-desc: the accessibility label, often used by screen readers
• text: the visible label on a button or field
• class: the type of Android view, such as android.widget.Button
• index: the element's position among siblings of the same class

Select an element in the inspector and Phoma highlights it on the phone screen. This visual confirmation is your first safety check.

Step 2: Read the tree before you pick a selector

Here is a simplified example of what the inspector might show for a login screen:

<android.widget.FrameLayout>
  <android.widget.LinearLayout>
    <android.widget.EditText
      resource-id='com.example.app:id/username_input'
      text=''
      class='android.widget.EditText'
      index='0' />
    <android.widget.EditText
      resource-id='com.example.app:id/password_input'
      text=''
      class='android.widget.EditText'
      index='1' />
    <android.widget.Button
      resource-id='com.example.app:id/login_button'
      text='Log in'
      class='android.widget.Button'
      index='0' />
    <android.widget.Button
      resource-id='com.example.app:id/forgot_password_button'
      text='Forgot password?'
      class='android.widget.Button'
      index='1' />
  </android.widget.LinearLayout>
</android.widget.FrameLayout>

Notice that resource-id values are namespaced to the app and tend to stay stable between releases. text values are visible to users and change when copy is edited. index values change whenever a sibling element is added or removed above the target.

Step 3: Choose selectors by stability

Rank selector attributes from most stable to least stable:

1. resource-id — Best choice when the app team owns the ID and does not refactor it.
2. content-desc — Strong choice for accessibility labels that are intentionally stable.
3. text — Acceptable for static labels, but risky if the app changes wording or supports multiple languages.
4. class plus index — Brittle. Avoid unless no other attribute is available.
5. position or screen coordinates — Most brittle. Do not use for flows that must survive updates.

In Phoma's step editor, configure the selector by attribute and value. For example, to tap the login button:

Step: Tap element
Attribute: resource-id
Value: com.example.app:id/login_button
Match: equals

This tells Phoma to find the element by its internal ID regardless of where it appears on the screen or what its visible text says.

Step 4: Handle dynamic and semi-dynamic attributes

Some apps generate IDs that include timestamps or build hashes, such as button_1a2b3c4d. If the suffix changes on every build, an exact match will fail.

First, check whether the prefix remains constant. If it does, use a "starts with" or "contains" match in Phoma's selector field so the step keeps working across builds:

Attribute: resource-id
Value: com.example.app:id/button_
Match: starts with

If no stable attribute exists, combine two attributes. For example, match class='android.widget.Button' and text='Log in' together. Phoma will narrow the results to elements that satisfy both conditions.

Avoid chaining too many attributes. A selector that depends on five attributes is harder to maintain than one that depends on one stable attribute.

Step 5: Verify before you save

Never save a flow step based only on the attribute string. Use Phoma's highlight or preview function to confirm that exactly one element lights up on the phone. If zero elements match, the selector is too narrow. If multiple elements match, the step may act on the wrong one.

Run the step manually once from the editor. Watch the phone screen. If the tap lands on the correct button, the selector is safe to use in a flow.

Real-world example: a weekly order-status check

A small business runs a weekly flow on five test phones. The flow opens a retail app, taps "Orders," and reads the status of the latest delivery. The original flow used index='2' to tap the Orders button because the inspector showed it as the third button on the home screen.

After an app update, a new promotional banner added a button at the top of the screen. The Orders button moved to index 3. The flow started tapping the banner instead, and the weekly check failed.

The fix was to re-inspect the screen, find that the Orders button had resource-id='com.retail.app:id/nav_orders', and rebuild the step using that ID. The flow now runs unchanged even when the home screen layout changes.

Do and don't

Do:

• Prefer resource-id and content-desc over text and index.
• Re-inspect screens after every app update.
• Verify each selector with Phoma's highlight before saving.
• Document which attribute each flow step uses so teammates know what to check if a step breaks.

Don't:

• Use screen coordinates or index positions for production flows.
• Build selectors around visible text that marketing can change.
• Select an element just because it worked once; confirm it is unique on the screen.

Sharing stable flows with your team

If you are on a Phoma Team or Business plan, save the verified flow to a shared phone pool. Teammates can run the same flow on their devices without rebuilding selectors. Because everything runs on your own computers and phones, there are no per-phone limits on the free plan, and sharing controls are handled in the Team and Business plans.

Stable selectors turn a flow that breaks every week into a flow that runs reliably until the app's underlying IDs actually change. Invest ten minutes in the inspector now, and you will save hours of debugging later.