אני בניתי תוכנה שנראית פשוטה עם AI כבר שנה שאני על הפיתוח ויש לי עוד מה להוסיף, לבנות תוכנות כאלו היום בAI זה מורכב, וודאי אם הכל חינמי

לא פשוט בכלל. זה פרויקט ברמת קושי גבוהה מאוד, ובפועל כמה פרויקטים קשים שמחוברים יחד. הנה פירוק לפי שלושת הרכיבים:

1. מנוע הרצה שקוף

• WSA (Windows Subsystem for Android) הופסק על ידי מיקרוסופט, והתמיכה בו נגמרה ב-2025, כך שאי אפשר לבנות עליו מוצר חדש.
• QEMU מצומצם אפשרי, אבל צריך להרכיב בעצמך תמונת Android (למשל מבוססת AOSP או Android-x86/BlissOS), לטפל בהאצת חומרה (WHPX או Hyper-V), בגרפיקה, במסך מגע ובאודיו.
• החלק של "פותח את חלון האפליקציה ללא ממשק אימולטור" הוא הקשה ביותר. צריך לשלב את חלון האנדרואיד כחלון נפרד של וינדוס, בדומה למה ש-WSA עשה, ואין לזה פתרון מוכן בקוד פתוח. אפשר לקרב את זה בעזרת scrcpy או שרת תצוגה משלך, אבל זה לא "שקוף" באמת.

2. רכיב לכידה באנדרואיד

• ל-Wi-Fi זה יחסית קל: האימולטור כבר מנתב רשת, ואפשר להשתמש ברשת של המארח ישירות.
• לבלוטות' זה בעיה אמיתית. אפליקציה באנדרואיד מדברת עם ה-Bluetooth stack (HAL ו-HCI), ולכן צריך לממש Bluetooth HAL מותאם בתוך התמונה, או לעקוף את ה-API ברמת המערכת (לדוגמה Xposed/LSPosed או שינוי ב-framework של AOSP). זה דורש בניית AOSP בעצמך, ומי שלא עבד על זה יתקשה.
• לכידה ברמת האפליקציה (hooking) שבירה: כל אפליקציה משתמשת ב-API קצת אחרת (GATT, Classic, BLE), ואפליקציות עם הגנות נגד root או hooking יזהו את זה.

3. גשר בווינדוס

• זה החלק הכי פשוט. ב-C# יש API טוב ל-BLE (Windows.Devices.Bluetooth) ול-GATT. Bluetooth Classic (RFCOMM) נתמך חלקית.
• הקושי הוא נאמנות מלאה: לתרגם בקשות GATT של אנדרואיד לווינדוס עם התנהגות זהה (חיבור, התראות, MTU, זמני תגובה) דורש הרבה בדיקות מול מכשירים אמיתיים.

הערכה כללית

• הוכחת היתכנות (אפליקציה אחת, BLE בלבד): חודשים ספורים לאדם מנוסה.
• מוצר יציב שעובד עם אפליקציות שונות: שנה ומעלה של עבודה, והרבה תחזוקה.
• הסיכון הגדול הוא ביציבות ובתאימות, לא ביכולת להראות שזה עובד בדמו.

חלופות שכדאי לבדוק לפני

• אם מדובר באפליקציה ספציפית, לבדוק אם אפשר לדבר עם ההתקן ישירות מווינדוס: ניתוח הפרוטוקול (למשל באמצעות לכידת HCI snoop log) וכתיבת לקוח משלך. לרוב זה הרבה יותר קצר מכל המערכת הזו.
• אם ה-Wi-Fi הוא החלק העיקרי, אימולטור רגיל עם רשת גשר כבר יספיק.
• Bluetooth passthrough של USB דרך QEMU/VM: מעביר דונגל בלוטות' פיזי ישירות למכונה הווירטואלית, וחוסך את כל שלב הלכידה והגשר. זה פחות "אלגנטי", אבל עובד היום.

מה האפליקציה שאתה רוצה להריץ ולאיזה התקן היא מתחברת? בזה תלוי איזה מסלול הגיוני.

כל APK

אם המטרה היא כל APK שהוא, התשובה משתנה: זה כבר לא פרויקט קשה, אלא כמעט בלתי אפשרי כמוצר שעובד באמת.

הסיבה היא שהפשרה שאפשר לעשות באפליקציה אחת (לנתח את הפרוטוקול ולכתוב לה לקוח) נעלמת. נשארת רק הגישה הכללית של לכידה וגשר, ושם כל אפליקציה מוסיפה בעיות משלה:

• כיסוי API מלא: צריך לתמוך בכל מה שאפליקציות עושות מול הבלוטות': BLE, Classic, A2DP, HID, SPP, וגם Wi-Fi Direct ו-Wi-Fi Aware. כל אחד מהם הוא מימוש נפרד, וחלקם אין להם מקבילה נוחה בווינדוס.
• הגבלות של ווינדוס עצמו: ה-API של ווינדוס לבלוטות' לא חושף הכל. אין גישה ישירה ברמת HCI מתוך אפליקציה רגילה, ולכן יש התנהגויות של אנדרואיד שפשוט אי אפשר לשחזר מעליו.
• אפליקציות עם הגנות: משחקים, בנקאות ואפליקציות עם Play Integrity או זיהוי אימולטור יסרבו לרוץ או יזהו את ההתערבות.
• חוויית משתמש: מסך מגע, חיישנים, מצלמה, התראות והרשאות צריכים כולם להתנהג כמו מכשיר אמיתי.

האם זה אפשרי בכלל? מי שניסה את הכיוון הזה כבר הוא מיקרוסופט עם WSA, והיא נכשלה בהרחבה לכל אפליקציה וזנחה אותו. גם BlueStacks ודומיו, עם צוותים גדולים, לא תומכים בבלוטות' באופן כללי.

מה כן אפשר לבנות במקום:

1. Passthrough של דונגל USB: פותר את הבלוטות' לכל אפליקציה בלי לכתוב קוד לכידה, כי אנדרואיד מדבר ישירות עם חומרה אמיתית. זו הדרך הריאלית היחידה לכיסוי רחב.
2. אימולטור קיים עם רשת גשר: מכסה את ה-Wi-Fi לרוב האפליקציות.
3. שילוב של השניים: אימולטור מוכן (למשל BlissOS על VM) עם דונגל מועבר, ועליו שכבת חלון נוחה. זה פחות אלגנטי ממה שתיארת, אבל זה מה שעובד.

אם בכל זאת רוצים ללכת על הגישה הכללית, כדאי להגדיר מראש רשימה סגורה של סוגי אפליקציות ותכונות שתומכים בהן, ולא להבטיח "כל APK".

האם הדגש הוא על שימוש אישי או על מוצר שתפיץ לאחרים? זה משנה הרבה את ההחלטה.